Position capturing and transmission using TCP

Hi,

I have a Turbo PMAC2-PC/104 and just started a project where I need to

get the position from the PMAC to a host connected with ethernet using TCP.

 

The position has to be captured on an external events of about 14 Hz, this

should be possible by using the Hardware Position-Capture function described

in the user manual. By connecting the external event to the USER Flag it

should be possible to configure the Hardware Position-Capture function so

that the position is latched every time the external event occurs. Is this

correct?

 

Another requirement is retrieval of the position via ethernet using

TCP. This TCP connection should preferably be initiated independently from

the motion program, which has its own TCP connection, in that case there

will be at least 2 simultaneous TCP connections to the PMAC.

 

I noticed that there is a command SENDP which can be used on the PMAC which

sends a message to the network communication port. From what I understand

this message then has to polled via a TCP connection. This makes me believe

that any TCP connection can flush this buffer which contains this

message. Is this correct?

If so it would compromise the retrieval of the position and also affect the

motion program.

 

There is also the possibility to retrieve register values directly from the TCP

connection. My questions here are: Is retrieval from one TCP connection

independent of another TCP connection? Or can the requested register value

be flushed from another TCP connection?

 

If the TCP connections are not independent from another and a requested

value can be flushed from another connection, the last option would be to

share the TCP connection between the two applications. Is this correct or is

there any other alternative?

 

Also worth to mention is that this Turbo PMAC has no DPRAM available.

 

Thanks!

You can do this over any communication port (USB/Ethernet, serial ...) but your host application will need to be able to do the following in the 14Hz time frame once the I-variables to make the user flag the capture flag (I7mn3=3 and I7mn2 set for the appropriate Flag only state: 2, 6, 10 , 14 ):

1. Read capture register to arm capture and save/process current captured value.

2. Poll capture flag indicating a capture - if true go to #1

3. Else go to #2

 

The above can be done in PMAC with PLC code and the value can be sent to the Ethernet port with CMDP"P99" where P99 is the captured data (assigned in the PLC at #1). The host program will need to monitor for unsolicited responses. Or the host can poll for changes in P99.

 

Note that PMAC has only one Ethernet port.

Thanks!

 

I feel that one question wasn't answered fully.

 

So if I for example have 2 TCP connections one for each application.

 

1st application, has its own TCP connection:

Motion program which sends jog commands, status commands etc.

 

2nd application, has its own TCP connection:

Poll for changes in the position capture register.

 

I want to use VR_PMAC_GETRESPONSE, from what I understand this actually polls the device. I cite the User manual "This packet causes the Ethernet connection to send a string to Turbo PMAC, then to return any available strings that may be residing in the Turbo PMAC."

 

Use case:

1st application, on its own TCP connection, sends ethernet command: VR_PMAC_GETRESPONSE.

 

Concurrent to this:

2nd application, on its own TCP connection, send ethernet command VR_PMAC_GETRESPONSE.

 

This seems like a racing condition to me. So depending on which TCP connection that performs the second part of VR_PMAC_GETRESPONSE, meaning "return any available strings that may be residing in the Turbo PMAC", first. This action may read the response meant for the other TCP connection. Essentially making the other connection timeout and fail to receive the response.

 

Please read carefully! Is this assumption correct?

 

Many thanks!

To have multiple host connections you need the Modbus enabled in the PMAC and use up to four sockets as PMAC ASCII. You must only use VR_PMAC_GETRESPONSE and the entire command must fit in one packet to keep each process atomic.

 

Send a request to support@deltatau.com and ask for the "Multiple Host Communication to PMAC" application note.

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?

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?

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

 

 

Yes, using different Interface as far as I understand it is no problem. I want to know whether it is possible for one tcp conection for ascii communication and another for DPRAM communication without interference?

No - the ASCII sockets are all tied to the PMAC "parallel" host port (USB/Ethernet/ISA/PCI). Communications on multiple sockets are only atomic in one "VR_PMAC_GETRESPONSE" command/response instance. Spanning multiple "VR_PMAC_GETRESPONSE" command/response sequences will get garbled.

 

In response to dchabot yes - this is sensible. The serial port is considered a separate port.

Thanks again, Steve.

 

I have one more question regarding ASCII communication.

 

I want to read multiple register within the the PMAC, several hundred registers, and I want to Issue the R[H]{address} online command.

 

First example:

Read 17 address in hexadecimal form:

 

rhl$004000 17

100000078400 110000078400 120000078400 130000078400 140000078400 150000078400 160000078400 170000078400 180000078400 190000078400 1A0000078400 1B0000078400 1C0000078400 1D0000078400 E0000078400 1F0000078400

200000078400

 

Note that there is a new line and carriage return after 16 reported values.

 

Second example, read 17 values in decimal form:

 

rl$004000 17

17592186536960 18691698164736 19791209792512 20890721420288 21990233048064 23089744675840 24189256303616 25288767931392 26388279559168 27487791186944

28587302814720 29686814442496 30786326070272 31885837698048 32985349325824 34084860953600 35184372581376

 

Note that there is a new line and carriage return after 10 reported values.

 

These tests are carried out in the PEWIN32 terminal over ethernet connection to the PMAC.

How come there is a newline and carriage return after 16 values when reading in hexadecimal form and 10 when reading in decimal form?

Seems weird that the number of reported values are somehow connected to the radix they are reported in.

 

Is there a way to get rid of the newline and carriage return all in all?

This is because of the "radix" of the two different number systems, base 16 (Hexadecimal) and base 10 (decimal). The least significant character will have 16 (for hexadecimal) or 10 (for decimal) values to display per line.

 

You cannot suppress the carriage return but you can suppress the linefeed by setting I3=0. Note that the Executive program will set I3=2 when it runs.

There is a line buffer of limited length in the PMAC. Base 16 can represent a value in ~10/16 the number of digits that Base 10 can, so it can fit 16 values on a line, when Base 10 can only fit 10 of these values.

Ok thank you very much.

 

I will be doing position capturing from external trigger, on a flag input on the servo IC. The capturing function is level triggered, however I would like to be certain to catch the exact position at the time for the trigger and not catch multiple position overwriting in each other.

 

So my question is what is the minimum time you have to keep the flag input active to catch exactly one position?

Hi,

 

The ASIC captures very quickly, something like the MHz range. So you don't have to have the input on very long. Furthermore, the captured position at trigger will not be cleared until you (or a PMAC program) reads the captured position, for example from Mxx73. For example, for Motor 1 on Turbo PMAC 2:

 

M173->Y:$0000CE,0,24,S ; #1 Encoder home capture position (cts)

 

This way, it won't capture multiple positions unless you read the position repeatedly.

 

I hope I've understood your question correctly, but let me know if I haven't.

Yes, thank you very much.