What are those “Simulation Commands” for, anyway?
Hopefully if you have any remote I/O at all, you’re using at least a couple of these commands as part of your I/O re-enable logic. As described in the doc that comes with this free download (click here):
“The logic in the IO Enabler sample strategy is designed to automatically recover communications to any I/O unit that temporarily goes offline (that is, has communications disabled) for any reason. An I/O unit typically goes offline if there is a power interruption to the unit, which might be caused by lightning or an electrical fault in the plant. When an I/O unit goes offline, IO Enabler logic ensures the best overall strategy performance as well as automatically recovering I/O unit communication.”
When else might I want to use these commands?
Would I ever want to purposely take my I/O Unit off-line? Sure. Here’s a situation that came up recently:
A professor at a university has some of our hardware in a lab (SNAP PAC Learning Centers) where students interact with the knob and switches hands-on. However, if a student can’t come to lab but would like to continue working on their assignment, the professor wants to use IP cameras and a [URL=“http://groov.com/description/”]groov Box (since that makes it super easy to connect a camera, throw on some buttons AND let students have access via a smart phone or whatever browser they have handy).
But how would he switch from using actual the switches and knob to “virtual” gadgets (via the groov interface)? As usual, we have several choices for how this could be done – including “simulating” the hardware which the students won’t actually be touching remotely.
Screenshot from groov View:
Here’s what I came up with, I’d be happy to hear if you have other suggestions. The basic idea:
Besides the usual “Convenience Store” strategy variables, we add one Integer 32 flag to determine if we’re in remote mode or not; one float variable to replace the knob; & three more Integer 32 variables – one for each of the switches used: Emergency alarm, Freezer Door, and Photo Sensor.
Notice in this case the OptoScript equivalent is much more compact since we can replace 9 blocks (3 condition and 6 action)…
…with just 3 lines of OptoScript code:
In case you want to copy/paste the OptoScript:
while (1) // loop forever // Block 1 - "Go remote?" condition if (IsVariableTrue( Remote_Option_On )) then // Block 6 - disable communication to real inputs DisableCommunicationToPoint( Fuel_Level ); DisableCommunicationToPoint( Emergency ); DisableCommunicationToPoint( Freezer_Door ); DisableCommunicationToPoint( Photo_Sensor ); // Block 8 - set Fuel Level IVAL from groov input // Because the Fuel_Level input point is disabled, using the command: // IvalSetAnalogPoint(groov_Fuel_Level_input, Fuel_Level); // (the command used in the Command Block equivalent) // would have the same result as this: Fuel_Level = groov_Fuel_Level_input; // Now update the 3 discrete values - using OptoScript we can // assign the values directly (rather than needing those 3 condition blocks) Emergency = groov_Emergency; Freezer_Door = groov_Freezer_Door; Photo_Sensor = groov_Photo_Sensor; else // Block 5 EnableCommunicationToAllIoPoints(); endif // Delay DelayMsec( 100 ); wend
OptoScript + Simulation commands + groov = whoo-hoo!