daves Posted March 28, 2014 Share Posted March 28, 2014 I have heard that it may be bad to not service the send commands with a running getsends process (IDE or whatever). Is this true? I have a system in the field running which will be doing a number of send commands, the IDE is not running and I have not explicitly started any getsends process. Is this a ticking timebomb which will grind to a halt? How should a project be set to run outside of the IDE? Link to comment Share on other sites More sharing options...
steve.milici Posted March 28, 2014 Share Posted March 28, 2014 The firmware engineers tell me this will not be a problem as the "stdio" mechanism will ignor them. Link to comment Share on other sites More sharing options...
daves Posted March 31, 2014 Author Share Posted March 31, 2014 Good to know, thanks Link to comment Share on other sites More sharing options...
daves Posted June 4, 2014 Author Share Posted June 4, 2014 I think I have evidence to the contrary on this. I would like a definitive answer on the suitability of using the send commands for debug. 1) If I start the IDE and unsolicited view, it fills with old messages that were emitted some time before. This implies they are not ignored but buffered somewhere and where there is a buffer there is the possibility of problems. Is it the same buffer as ASCII commands? 2) I have a start up PLC with LOTS of the code of similar to this: sub: CentreAxes_MainAcc24E2A(void) send 1 "DefineHardware.CentreAxes_MainAcc24E2A: Started"; send 1 "DefineHardware.CentreAxes_MainAcc24E2A: Define pointers"; // Centre come from axis cards Ldata.CmdStatus = 1; cmd "R1AmpFault->u.io:$618020.23.1"; ... MORE... callsub sub.SendCmds(1); return; sub: SendCmds(Error) // Force commands from buffer sendallcmds; // Wait for command to execute while (Ldata.CmdStatus > 0) {} // Error in execution? if (Ldata.CmdStatus < 0) { errorDefineHW = Error; // Handle the error send 3 "------ DefineHardwarePointers: error %d", Ldata.CmdStatus; } return; If I don't have the IDE unsolicited running my HMI times out (on 10s), if it is running it takes a second or so (I have not done accurate measurements). If I comment out all the sends, it runs in about a second. This indicates an impact on performance (a choke). 3) When using the IDE unsolicited I often see corruption of the messages. In particular the first half of one message, then a second message concatenated, then the next line. Or the messages from one PLC up to a point then no more even though the plc has finished. 4) Without the IDE unsolicited running I have observed ASCII commands issued from a background C program (GetResponse command) occasionally go missing. This is potentially dangerous. I haven't done a full study but I haven't seen it with the IDE running. This is a potentially really useful feature and I was making heavy use of it. Now, however, I have had to comment out all send commands to get a reliable system. Please can you address all these points. Thanks Dave Link to comment Share on other sites More sharing options...
Felix Posted June 9, 2014 Share Posted June 9, 2014 I second Dave's observation. We also heavily use send statements for debugging in our code and have run into the same issues. We had to resort to guarding our send statements by a if (DoSend) send 1,.... construct. Regards, Felix Link to comment Share on other sites More sharing options...
fahmad Posted June 9, 2014 Share Posted June 9, 2014 "getsends" has been replaced with new process "sendgetsends". This process can send and receive messages on 8 ports Port0 - Port7. Latest PowerPMAC IDE (due to be released withing this month) supports all 8 ports. From within the IDE, Port0 is enabled by default for debug messages and all other ports are disabled at startup. These ports port1-port7 are available for users' messages. Further, if the port is in use then user gets a port-busy error message and will not be able to connect to it until previous client has closed the connection. Although "sendgetsends" is an independent process, I will update everyone after talking to Ed Lay regarding load issue. Link to comment Share on other sites More sharing options...
daves Posted June 10, 2014 Author Share Posted June 10, 2014 Thanks Fahmad I hope this addresses point 3. The critical problem in my post is on systems not running any getsends. The problem is the sending end choking, not the receiver. It is very easy to demonstrate, please try this: global DoSend = 0; open plc 1 local iLoop; p1,1000 = 0; p0 = Sys.Time; iLoop = 0; while (iLoop < 100) { if (DoSend) { send 1, "one two three four five six seven eight nine ten eleven twelve thirteen fourteen fifteen sixteen seventeen"; } callsub sub.DoCmd10(1 + iLoop * 10); iLoop++; } p0 = Sys.Time - p0; disable plc 1; return; sub: DoCmd10(Num) local iLoop; Ldata.CmdStatus = 1; iLoop = Num; while (iLoop < Num + 10) { cmd "p%d=%d", iLoop, iLoop; iLoop++; } return; close put P0,P100,P200,..,P900,P1000 in a watch Download Hide the Unsolicited tab enable plc 1 You see the P100 etc fill. It takes 1.14s (P0) on my system. DoSend=1 enable plc 1 You see the P100 etc fill in an unstable manner. It takes 101.05s. Show the unsolicited view enable plc 1 You see the P100 etc fill. It takes 1.15s. Link to comment Share on other sites More sharing options...
daves Posted September 1, 2014 Author Share Posted September 1, 2014 This is still the case in 1.7.0.53/1.6.1.1. I still see issues 1 and 2. Is this going to be addressed as we need to know if this system can be used for error logging reliably Link to comment Share on other sites More sharing options...
Recommended Posts