Laserdave7 Posted September 10, 2012 Share Posted September 10, 2012 Hi Guys, I'm having a problem with inconsistent unsolicited messages. I'm using a GeoBrick over USB and Procomm Server. I am trying to send a message to the host to command it to change laser parameters. I have the following code loaded in the Brick: ;############################################ ;M70 - Set Laser Q Rate N70000 Read(Q) If (PARAM_INCLUDED & Q_PARAM_FLAG > 0) TEXT_NO_CR=1 ;I62 P301=Q117 SendP"QRATE " CmdP"P301" Endif Return I run a simple program "M70 Q30000" Sometimes I get 'QRATE' and '30000'. Sometimes I get just 'QRATE'. Sometimes Just '30000'. I see this in my code as well as in PEWin32 Pro2. I have tried putting dwells as large as 100 after each SEND/CMD but no help. How can I make this robust. I need to know that this will be 100 percent consistent. Is there a better way to accomplish what I'm trying to do? Thanks, Dave Link to comment Share on other sites More sharing options...
steve.milici Posted September 10, 2012 Share Posted September 10, 2012 Use the feature described by I64 for unsolicited messages (see the Turbo SRM page 46 - electronic page 64). This would be the most robust method. Link to comment Share on other sites More sharing options...
Laserdave7 Posted September 10, 2012 Author Share Posted September 10, 2012 Hi Steve, I currently Have I64=1. This issue shows up in PEWIN32 with none of my software running. I closed the position display, the MotorStatus, and the Watch windows to eliminate as much polling as possible. It seems to reduce the errors, but I still get dropped messages. Dave Link to comment Share on other sites More sharing options...
steve.milici Posted September 10, 2012 Share Posted September 10, 2012 If you have your own application reading the responses the Executive will interfere. If you are just using the Executive's response window to view these it will miss some of the data as more windows are opened. If you just have the terminal window opend set the thread delay to a slow rate - this may help a bit. Link to comment Share on other sites More sharing options...
Laserdave7 Posted September 11, 2012 Author Share Posted September 11, 2012 Thanks for the info Steve. This is consistent with what I am seeing. If I close everything other than the terminal window (PEWin32) to execute the program and view responses in the Unsolicited tab at the bottom, I get mostly correct but missing once in a while. This is a concern for me because it means I can't use this deterministically. Is this issue: timing on the GeoBrick or in the PCOMServer? I noticed that there is an "Interrupt" event in PComServer and that serveral of the interrupt values were labeled as user definable (In sample code that comes with PCOMServer) but I haven't found anywhere in the manual that explains how to use these yet. Would these be any more deterministic? If not then I think my solution will be to use the digital IO to function as an interrupt to the computer and then retrieve the info in solicited fashion. Thanks, Dave Link to comment Share on other sites More sharing options...
steve.milici Posted September 11, 2012 Share Posted September 11, 2012 Our Executive is a multi-threaded application. We do not guarantee that the responses preceded with the -B picked up by another thread is passed to the unsolicited response window. Your application can be written to guarantee this. Link to comment Share on other sites More sharing options...
Laserdave7 Posted September 11, 2012 Author Share Posted September 11, 2012 Is PCommServer also multithreaded? My application is experiencing the exact same problem. Will PCommServer fire unsolicited events from multiple threads? If so I can put a lock in my code to force sequencing... Thanks Link to comment Share on other sites More sharing options...
Recommended Posts