[B]What are those “Simulation Commands” for, anyway?[/B]
Hopefully if you have any [B]remote I/O[/B] 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.”
[B]When else might I want to use these commands? [/B]
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/”][I]groov [/I]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 [I]groov [/I]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 [I]groov [/I]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 [B]alarm[/B], Freezer [B]Door[/B], and [B]Photo [/B]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 + [I]groov [/I]= whoo-hoo!