Jump to content
OMRON Forums

C programming PPMAC commands


AnthonyLH
 Share

Recommended Posts

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

Link to comment
Share on other sites

  • 4 weeks later...
  • Replies 3
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

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

Link to comment
Share on other sites

  • 2 years later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...