Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Global defined string?
#1
We want to "pass" a string from the rticplc to a plc script (for populating a motion program buffer). While it is simple to create and manipulate strings within plc/rticplc individually, I can't seem to find a convenient way of defining and accessing global strings.

A bit of background: The rticplc will be handling comms, and as the Command"" function in gplib appears not to be available for cplc's, the plc routine is used for writing to the motion program buffer and controlling the CS. We could use a capp, with Command"" calls for all motion program & CS control, but the plc (running on rti) needs to exist for safety monitoring anyway.

So far the best way I can find to "communicate" between plc/cplc is with global flags & the use of "pshm->" or SetGlobalVar(), but this does not really help with strings. Perhaps it is possible to reserve a block of user shared mem by defining a global ptr to Sys.Cdata[i] for multiple characters?

Any suggestions would be much appreciated.

Additionally, I would like to clarify use of Command"" in cplc's because the gplib header states that it is not to be used anywhere other than in C apps. Is this the case, or is it "safe" to use in cplc's (either rti or bg)?

Thanks
Reply
#2
I haven't worked with them in years but it was my understanding that the cplc's were nothing more than predefined c program threads running under xenomai realtime. I don't see why the command() function would be different under cplcs as opposed to "background C apps" unless the cplc's run under a different context such as kernel mode threads. You might give it a try.

I would do the interfacing to the motion buffer and coordinate system stuff in a "background C app". Just much more power and control over how it executes and how many threads you can have in one process.

I'd advise against doing any communications in rti, this needs to be deterministic. Maybe I'm misunderstanding you?

KEJR
Reply
#3
(11-01-2017, 05:41 AM)KEJR Wrote: I haven't worked with them in years but it was my understanding that the cplc's were nothing more than predefined c program threads running under xenomai realtime. I don't see why the command() function would be different under cplcs as opposed to "background C apps" unless the cplc's run under a different context such as kernel mode threads. You might give it a try.

I would do the interfacing to the motion buffer and coordinate system stuff in a "background C app". Just much more power and control over how it executes and how many threads you can have in one process.

I'd advise against doing any communications in rti, this needs to be deterministic. Maybe I'm misunderstanding you?

KEJR

No misunderstanding, and I have not found a reason for avoiding use of Command"" in cplc's other than the firmly worded commenting in the header. Also we have used the command function before in both rti/bg cplc's and not encountered issues, though the caution is dully noted regarding rticplc!

I would prefer to have all motion buffers & CS control handled via a C app, and perhaps you could comment on this, as when I enabled the capp as RT it nearly caused the pmac to hang. I ran it at the default priority "BACKGROUND_RT_PRIORITY-10", but perhaps I should run at "script_priority-10" or there are further settings I should be aware of (part of the reason for using plc/cplc's is my somewhat lesser familiarity of linux scheduling/threading).

Thanks
Reply
#4
To the OP, yes, Sys.Cdata[i] is the way to do this. Use char* pointers to write to this array in C and sprintf to write to it in PLCs. As for reading this and passing it to a start command in a PLC, I believe you can use the string formatting features of cmd"" to transfer the string living in Sys.Cdata[i] to your "R" command.

Another way around is to parse /usrflash/Project/Database/pp_prog.sym for all program name-to-number equivalencies at startup in a C program (in your case RTICPLC, so this would have to be the first of its tasks at powerup, and once done, never repeat that in further iterations), store those in a big array in user space, write the corresponding number of the program name you want to use to a Sys.UData[i] array element, and call that using the start command in a PLC. This would mean a bigger startup, but ultimately probably less "communicating" for your RTICPLC to do.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)