Thread Rating:
  • 1 Vote(s) - 1 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Write to buffer (Rotary) from C
#1
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?
Reply
#2
Bump... This would be a very useful feature for our application.
Reply
#3
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.
Reply
#4
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.
Reply
#5
(05-07-2013, 03:01 PM)curtwilson Wrote: 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(...
Reply
#6
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", <<Parameters>> );
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
Reply
#7
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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)