[Position capturing and transmission using TCP]

I have also been considering similar problems.

 

I would like to know if it is possible to avoid contention in position-capture applications by using

the serial and ethernet ports simultaneously:

 

1) "Slow control" (position commands and status) over the serial port, and

2) "Position-capture data transfer" over the ethernet port

 

It is my understanding that the serial and ethernet ports are independently serviced by the

PMAC, so contention may be avoided in this fashion.

 

Is this sensible?

 

 

-- dc

 

 

Thanks Steve!

 

One further question, the current PMAC we are using doesn't have the dual-port RAM. But we are considering to use this in the future because we have to do big data transfers.

 

My question is if there is dual-port RAM, can there be two TCP connections:

 

1st TCP connection:

Handling ASCI communication.

 

2nd TCP connection:

Only accessing the dual-port ram.

 

Without interfering with each other?

 

Or does the ASCI communication interfere with the dual-port RAM access as well?

(by sharing an input/output buffer or something similar)

 

Or you still need to configure it to modbus setup?

[nano positioner tuning]

One of the following could be true:

- Friction or sticktion effect in one direction or the other. You may have to implement some gain scheduling (higher PID gains where needed).

- You are exceeding the maximum speed dictated by the DC bus.

- You are exceeding the maximum acceleration dictated by the current.

- The last two are essentially what we call a servo effort. Violating the servo effort, in general in closed loop, will cause a fatal following error.

 

That said, it seems like you are tripping on the acceleration section (Ixx19 for jog moves).

Have you tried slower accelerations?

I don't know how good your tuning is. But you might want to look into adding some friction feed forward (Ixx68).

 

I think my tuning is ok. Step and ramp tuning results for one of the problematic axes are here

 

I've tried adjusting velocity and acceleration, neither of which was successful. But, I will look into the adaptive control scheme you suggested (gain scheduling).

 

I've also swapped drives between fully functional and problematic axes, and the problem follows the stage, not the drive.

 

At this point, I'm fairly convinced it is a mechanical problem...

[nano positioner tuning]

I have an piezo motor application that is displaying problematic behavior under closed-loop control for some (not all) axes.

 

The system is a Geobrick LV (NSLS-II) outputting step/direction to six MiCos PMC-100, which drive nanopositioner stages (stick-slip piezo). Feedback is via a MicroE incremental linear encoders ( 0.005 um resolution).

 

I myopically tuned all 6 axes of this system for small moves (0.25-5 um), as that is how it is used in practice. On further investigation, 3 of the 6 axes trip on fatal following error for longer moves, but only in one direction (Ixx11 = 32000) . The other direction is fine. The problematic axes trip on this error a fraction of a second after a commanded move (J+/J-, etc), regardless of Ixx22 setting (jog speed).

 

Gravity is not an issue here as one of two of the vertical stages works fine in closed-loop.

 

Is there any way to tune for this type of behavior? I'm kinda at a loss here...

 

Thanks.

[DHCP support]

Does the Geobrick LV support having its network address assigned via DHCP or BOOTP?

 

Or is it static assignment only via the "Configure Ethernet 100 BaseT" utility? There is a "Reg DHCP" button in this utility that, to me, hints DHCP config is possible, but I don't know the procedure.

 

 

-- dc