tweekzilla Posted April 24, 2013 Share Posted April 24, 2013 I have a TCP server that currently transmits various status/Positions etc on a deterministic basis (xenomai user-space task) to a python client. I would like to be able to use the same socket to transmit from the python client to the PMAC updated positions in a rotary buffer. Is there a way in a C program to add commands to the Rotary buffer? Link to comment Share on other sites More sharing options...
tweekzilla Posted May 1, 2013 Author Share Posted May 1, 2013 Bump... This would be a very useful feature for our application. Link to comment Share on other sites More sharing options...
curtwilson Posted May 7, 2013 Share Posted May 7, 2013 Sending program command lines to the rotary buffer can be done simply by sending text through gpascii. You can get a feel for doing this simply by typing lines into the terminal window in the IDE or through a terminal emulator like cmd.exe. Link to comment Share on other sites More sharing options...
tweekzilla Posted May 8, 2013 Author Share Posted May 8, 2013 Some more information - Our current setup uses a 300hz Xenomai thread to log pmac variables into a posix message queue. A 10hz Xenomai thread then sends that data over the network and receives new position information from the control computer. The idea is that this thread then puts the new positions into the Rotary Buffer - the whole transaction is psudo deterministic with error checking etc. This gets really ugly if we have to open a telnet session in a xeonmai thread, log in, run gpascii and set things up. Ideally would be able to append the new positions directly from the C-code as they come in to the memory location of the next buffer command. An alternative would be if we could connect to a port on the PMACSERVER and send commands that way. This would be somewhat cleaner from a C-thread. Link to comment Share on other sites More sharing options...
JeffLowe Posted May 10, 2013 Share Posted May 10, 2013 Sending program command lines to the rotary buffer can be done simply by sending text through gpascii. You can get a feel for doing this simply by typing lines into the terminal window in the IDE or through a terminal emulator like cmd.exe. gpascii is all fine and good from the cli to enter single lines, or to even dump a file in, but for for programmaticaly streaming data onto the rotary buffer it is tedious: Create a named pipe for input, create another for output, and a third for error. Fork and exec an instance of gpascii with the three fifos as stdin, stdout, and stderr. Start a program to capture and flush the Acks coming out of the gpascii, start another program to read and capture any errors and take appropriate action, start a third program that transfers the lines to the rotary buffer via writes to the fifo attached to stdin. a fourth program or plc is handy to watch all of this and kill off these process in the event of error, or issue run stop, step, etc. I really miss the PComm function: MyPmac.DPRAsciiStrToRotEx(... Link to comment Share on other sites More sharing options...
AnthonyLH Posted July 24, 2014 Share Posted July 24, 2014 I would like to continu on the subjet. We also would like to send "rotary buffer" command lines from a RTICPLC more directly. Currently we send this type of command: sprintf(L_sTemp,"&%d open Rotary N%d X%.6le Y%.6le Z%.6le A%.6le B%.6le C%.6le Q_Par1==%ld Q_Par1==%d close", <> ); L_iReturn=Command(L_sTemp); "Command" from my understanding give access to a GPASCII, so from my understanding we loose the real-time. Also the "GASPII" session accessed by command is shared by all calls in the RTI. So if an error occurs, the buffer can stay opened and all other command by rejected (sent in the rotary...). Do you have another "rotary buffer" direct access we could used ? Our goal: We have a trajectory generator running in RTI which fills the rotary buffer. Our current objective is a TM of 5ms, so to send a command in the rotary every 5ms. We also want to reduce as much as possible time between the command send and its traitment (as less lines as possible in the rotary) so that calculated trajectory is played "as fast as possible" An ideal command will be: N (Sys.nsync), 6 positions (X,Y,Z,A,B,C), 2 Q variables for internal use. I will also be interested if you have a faster solution when sending only the 6 positions (X,Y,Z,A,B,C). Thank you Link to comment Share on other sites More sharing options...
curtwilson Posted July 28, 2014 Share Posted July 28, 2014 A common way of doing this type of task is with a fixed motion program executing in a looping fashion - e.g.: tm5 while (DoingThis) { MyNsyncVal = ... MyXpos = ... MyYpos = ... MyZpos = ... MyApos = ... MyBpos = ... MyCpos = ... MyQvar1 = ... MyQvar2 = ... N(MyNsyncVal) X(MyXpos) Y(MyYpos) Z(MyZpos) A(MyApos) B(MyBpos) C(MyCpos) } By doing all of the computation and move commands in a single synchronized and sequenced thread, you eliminate all sorts of problems with handshaking and possible loss of synchronicity. Link to comment Share on other sites More sharing options...
Recommended Posts