Jump to content
OMRON Forums

sendN and getsends questions


erikj

Recommended Posts

Hi DT Support, I have been testing my Java motion control codes using gpascii and getsends and have experienced some interesting behavior, which leads me to some questions: 1. At the motion program level, is the sendN command thread safe? If I have multiple programs writing with the send0 command, can they clobber each other? I am guessing they can. 2. I am using send0 and getsends to indicate completion of a move. I write a completion message using send0 and then I have a thread on my remote host that reads the output of getsends to get the completion message. I find that if I command my motor repeatedly to move to its current position in rapid succession that getsends does not receive all the completion messages. I am commanding a single motor and I wait until the motion program is complete before executing the next move command. It appears that I may be writing to the send0 buffer faster than getsends can pick it up. Can you tell me what the maximum rate is that I can expect getsends to reliably pick up new messages? Note that I do not expect to use the system in this way for normal operations, but testing like this helps to simulate what might happen if commands for multiple motors arrive asynchronously at nearly the same time. I have included a listing of my motion program below. The value in Q1 is the new position to move to. The value in Q2 is the iteration number so I can track which response I am receiving in getsends (for testing purposes only). Thanks, Erik list prog2 rapid abs X(Q1) send0"M[%d]:inPos %d",Ldata.coord,(Q2)
Link to comment
Share on other sites

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

[quote='erikj' pid='1301' dateline='1297201438'] Hi DT Support, I have been testing my Java motion control codes using gpascii and getsends and have experienced some interesting behavior, which leads me to some questions: 1. At the motion program level, is the sendN command thread safe? If I have multiple programs writing with the send0 command, can they clobber each other? I am guessing they can. --- Yes its thread safe because the PPmac can only do one task at a time. So one send will be done before the next program executes and does its send. This does not mean the send is sent and recieved by getsends. It means it is in a buffer waiting to go out. 2. I am using send0 and getsends to indicate completion of a move. I write a completion message using send0 and then I have a thread on my remote host that reads the output of getsends to get the completion message. I find that if I command my motor repeatedly to move to its current position in rapid succession that getsends does not receive all the completion messages. I am commanding a single motor and I wait until the motion program is complete before executing the next move command. It appears that I may be writing to the send0 buffer faster than getsends can pick it up. Can you tell me what the maximum rate is that I can expect getsends to reliably pick up new messages? Note that I do not expect to use the system in this way for normal operations, but testing like this helps to simulate what might happen if commands for multiple motors arrive asynchronously at nearly the same time. --- Are you saying you are sometimes missing data or that sometimes you get one send string and other times you get two or three from the sendgetsends(). I would expect the later. You can try with a sendall after the send in the motion program. I have included a listing of my motion program below. The value in Q1 is the new position to move to. The value in Q2 is the iteration number so I can track which response I am receiving in getsends (for testing purposes only). Thanks, --- It will take me awhile to get a test going. Perhaps the above info will help you in the meantime. Erik list prog2 rapid abs X(Q1) send0"M[%d]:inPos %d",Ldata.coord,(Q2) [/quote]
Link to comment
Share on other sites

[quote='bradp' pid='1303' dateline='1297203898'] [quote='erikj' pid='1301' dateline='1297201438'] Hi DT Support, I have been testing my Java motion control codes using gpascii and getsends and have experienced some interesting behavior, which leads me to some questions: 1. At the motion program level, is the sendN command thread safe? If I have multiple programs writing with the send0 command, can they clobber each other? I am guessing they can. --- Yes its thread safe because the PPmac can only do one task at a time. So one send will be done before the next program executes and does its send. This does not mean the send is sent and recieved by getsends. It means it is in a buffer waiting to go out. 2. I am using send0 and getsends to indicate completion of a move. I write a completion message using send0 and then I have a thread on my remote host that reads the output of getsends to get the completion message. I find that if I command my motor repeatedly to move to its current position in rapid succession that getsends does not receive all the completion messages. I am commanding a single motor and I wait until the motion program is complete before executing the next move command. It appears that I may be writing to the send0 buffer faster than getsends can pick it up. Can you tell me what the maximum rate is that I can expect getsends to reliably pick up new messages? Note that I do not expect to use the system in this way for normal operations, but testing like this helps to simulate what might happen if commands for multiple motors arrive asynchronously at nearly the same time. --- Are you saying you are sometimes missing data or that sometimes you get one send string and other times you get two or three from the sendgetsends(). I would expect the later. You can try with a sendall after the send in the motion program. I have included a listing of my motion program below. The value in Q1 is the new position to move to. The value in Q2 is the iteration number so I can track which response I am receiving in getsends (for testing purposes only). Thanks, --- It will take me awhile to get a test going. Perhaps the above info will help you in the meantime. Erik list prog2 rapid abs X(Q1) send0"M[%d]:inPos %d",Ldata.coord,(Q2) [/quote] [/quote] Hi Brad, Thanks for the reply. It looks like I am getting the latter response you describe, where multiple sends are combined in a single getsends response: Iteration: 63 getsends: -0: M[1]:inPos 63 Iteration: 64 Missed callback for iter: 64 Iteration: 65 getsends: -0: M[1]:inPos 64M[1]:inPos 65 Iteration: 66 getsends: -0: M[1]:inPos 66 I will try parsing for this. Thanks, Erik
Link to comment
Share on other sites

I just tested 2000 sends and did not get any skips. I modified your code a little and did the test from script language. Here I just start plc2 and let it run awhile and let the IDE capture the sends. Of course the IDE gets very far behind but sooner or later all the data comes out. open prog 2 rapid abs X(Q1) q2++ send0"M[%d]:inPos %d",Ldata.coord,(Q2) dwell0 p1=1 close open plc 2 if(Coord[1].TimerEnabled == 0 && P1 == 1.0) cmd"p1=-1 &1b2r" close
Link to comment
Share on other sites

[quote='bradp' pid='1305' dateline='1297206087'] I just tested 2000 sends and did not get any skips. I modified your code a little and did the test from script language. Here I just start plc2 and let it run awhile and let the IDE capture the sends. Of course the IDE gets very far behind but sooner or later all the data comes out. open prog 2 rapid abs X(Q1) q2++ send0"M[%d]:inPos %d",Ldata.coord,(Q2) dwell0 p1=1 close open plc 2 if(Coord[1].TimerEnabled == 0 && P1 == 1.0) cmd"p1=-1 &1b2r" close [/quote] Hi Brad, Your PLC program is essentially doing the equivalent of what my Java code is doing on the remote host, except it gets the completion notification by monitoring p1. I tried your sendall idea, and that seems to have fixed it. Presumably that forces the buffers to be flushed and the information sent so that getsends can pick it up. I have tried it several times and have not missed a callback yet. Thanks again for your help! Erik
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...