C programming PPMAC commands

[AnthonyLH]

Dear all,

 

I have a security issue using "Command(...)".

In the Rticplc, it seems that the "Command(...)" use a unique gpascii thread for all "Command(...)" requests (i don't know for others: capps, bgcplc..).

I use the "Command(...)" for a lot of interraction with PPMAC (jog, abort, disable...), in one application i even fill up a rotary buffer.

When you send an "open rotary" from a "Command(...)", all the next "Command(...)" will be send in the rotary.

To avoid this, i always send the "open rotary" and "close" in a single command not to leave the gpascii thread opened in a rotary.

Even taking this precausion, i something get stock in an opened rotary, all my next commands are rejected (abort, kill...)

 

So my questions:

 

In C programming (Capp, Bgcplc, Rticplc, Usrcode...), what are Deltatau preconisation to interact with the PPMAC world for stop command (abord, disable...):

- we can use predefined C PPMAC Commands (AbordCoord, KillAllMotors..) but there are not all available.

- we can use the standard "Command(...)"

- other method?

 

Does predefined C PPMAC Commands (AbordCoord, KillAllMotors..) use the same gpascii thread than the command "Command(...)" ?

 

Does it exist a documentation listing and explaining the C PPMAC commands (AbortCoord, GetResponse) ?

 

Thank you all

[KEJR]

I've had pretty good luck using command() for many basic things in PPMAC like jogging, enable/disable in background C apps. So far I've not had any issues with multithreading and using command() (although I admit I've not done much multithreading with the command interpreter).

 

One thing I will say is that I would not be doing anything in the rtiCPLC that uses command interpreters and such. I've not used this facility yet but it is my understanding that the rticplc is meant for quick hard realtime tasks (data gathering and processing at hard realtime interrupt speeds). I'd highly recommend using background C apps or CPLC's if you want to take full control from a C environment such as starting a jog or enabling a motor.

 

Leaving your realtime interrupt tasks operating purely on native C calls and memory access will make your life much simpler in the end.

 

KEJR

[gmschoon]

I've had pretty good luck using command() for many basic things in PPMAC like jogging, enable/disable in background C apps. So far I've not had any issues with multithreading and using command() (although I admit I've not done much multithreading with the command interpreter).

 

One thing I will say is that I would not be doing anything in the rtiCPLC that uses command interpreters and such. I've not used this facility yet but it is my understanding that the rticplc is meant for quick hard realtime tasks (data gathering and processing at hard realtime interrupt speeds). I'd highly recommend using background C apps or CPLC's if you want to take full control from a C environment such as starting a jog or enabling a motor.

 

Leaving your realtime interrupt tasks operating purely on native C calls and memory access will make your life much simpler in the end.

 

KEJR

 

We have been using Command() in an rticplc and while it seems to work fine, we have encountered text in the gplib header file that says the command (and TS variant) are for use only in "capp":

 

/// These functions are for use as an API for linux "C" APPs.

/// \warning They are NOT available to user written real time "C" PLCs.

 

While I can appreciate that avoiding use of Command() in an rticplc makes sense, this header comment would strongly suggest that it should not be used in a bgcplc either.

 

Any comments on this?

 

Thanks

[KEJR]

I can't comment on the headers since I didn't write them ;-) All I know is that I've been told that we could use the command interfaces to start motion and what not from C programs (i.e. background C programs).

 

This is just my opinion but I would not recommend doing anything in the RTI involving non-deterministic behavior (like a command processor). I am not sure what Delta Tau has to say about this but I would guess they feel the same given that header comment. YMMV

 

 

We have been using Command() in an rticplc and while it seems to work fine, we have encountered text in the gplib header file that says the command (and TS variant) are for use only in "capp":

 

/// These functions are for use as an API for linux "C" APPs.

/// \warning They are NOT available to user written real time "C" PLCs.

 

While I can appreciate that avoiding use of Command() in an rticplc makes sense, this header comment would strongly suggest that it should not be used in a bgcplc either.

 

Any comments on this?

 

Thanks