Anyone have any ideas on toggling a bit from Groov. I can use a Command Button to set a 1 or 0, using a Button I can turn on a bit and then turn it off, but what about a toggle button.
Thanks
Anyone have any ideas on toggling a bit from Groov. I can use a Command Button to set a 1 or 0, using a Button I can turn on a bit and then turn it off, but what about a toggle button.
Thanks
Hi Gar,
Welcome to the OptoForums!
Are you connecting from groov to a PAC? Or some non-Opto 22 hardware?
Assuming you have a PAC here: toggling a bit is not something you can do DIRECTLY via groov (at least not yet, as of this writing/version 2.1). However, with a little bit of logic in your strategy, it’s pretty easy.
You could create a button that sends the specific bit you want to toggle (here I’m assuming you want to change just one bit of a 32-bit integer, so the valid range to send is 0 - 31).
Then in a looping chart somewhere, or, as I’ve picture here, in a dedicated chart for this purpose, loop checking for a valid range on this bit number, which I called nBitToToggle. The bit mask to change I’ve called: nMyMask. The command to actually do the toggling would be [B]Bit XOR[/B], like so:
repeat
if ((nBitToToggle >= 0) and (nBitToToggle < 32)) then // we want to toggle a bit, and it's in a valid range for an int32
nMyMask = nMyMask bitxor (1 << nBitToToggle);
nBitToToggle = -1; // we've toggle the bit, we're done, now clear the "command" so we don't continue to toggle
endif // we're just ignoring values 32 and over
DelayMsec( 500 ); // half the groov scan time
until (0); // loop forever
Let me know if OptoScript is not your thing, I’ll whip equivalent logic done in blocks.
Hope this helps!
-OptoMary
Sorry, I haven’t gotten back sooner several projects going on. All AB here, the one I’m looking at is CompactLogix on RS5000.
I gave them a button and reminded them to make sure they turn it back off before they walk off.
Gar, do you mean a momentary?
Its a 1 for as long as you hold it down?
Im just not sure what you mean as ‘toggle’…
Do you want the button to look at the state of the point and make it the inverse of what ever its current state is?
A sort of ‘read-before-write’ thing?
Yes a momentary button, right now when they cut on the button they have to remember to cut it off before they walk off. The button is being used to release a cab on a conveyor from a stop, when they release the cab the stop must be closed before the next cab gets to the stop. With a momentary button the bit will not be held and the stop will close itself with the cab clear limit.
Ah, righto…
Cant say too much, but be sure and keep up to date with all things groov.
(If your not already, subscribe to our emails here http://groov.com/keep-me-informed/)
What a mysterious answer from Ben! The suspense is killing me.
This actually brings up an interesting point on the reliability of data commands from wireless devices. For any safety related issues the question should always be asked “what happens if my data connection fails right NOW”.
Its fine to have a start button and a stop button for a pump, but what if your wireless data-link fails just when you want to stop the pump. Of course wireless communication is 99% reliable, but what about that other 1%? Once you ask yourself that question, software design becomes a different ballgame.
I.e. if the controller does not receive a confirmation of operator presence, should the PAC automatically activates safe state logic at the controller level?
Instead of a button, I prefer to use an horizontal slider which writes to a float or integer value to the controller. A value greater than zero is considered as a ON command. PAC logic must be added to internally ramp the value down to zero, which is then considered as an OFF command. (Writing directly to Downtimers is currently not supported in groov :mad:)
If the operator wants to an output as ON, he slides the value to required runtime value.
If the operator wants to an output as OFF, he slides the value to zero.
If the operator wants the output ON longer, he slides the value again before the value reaches zero.
If the operator forgets to slide the value to maximum, output will automatically go OFF when value reaches zero.
That way, even if the wireless connection is lost, process safety is still ensured. The concept is that of a “Dead man’s switch” Dead man's switch - Wikipedia but in addition to checking for dead operators, you are also adding security in the unlikely event of communications infrastructure failure.
If you consider that for offsite remote mobile connections , your groov connection may pass through several cell towers, phone companies, states or even countries, not to mention your own site infrastructure, its well worth thinking about before implementing remote control functionality to the mobile interface. Just saying 
George,
Nice post! Very insightful and spot on…
Its worth keeping what you mention in mind for any operator interface, be it groov or PAC Display or some other vendors.
What happens to the control system when it goes away?
Naturally, as you point out, its more possible for a dropout to occur from a mobile aspect than hard wired, but its still something that I had to keep in mind when building operator interfaces at the hospital.
Regarding timers; Cant say too much, but be sure and keep up to date with all things groov.
(If your not already, subscribe to our emails here http://groov.com/keep-me-informed/)
A few more thoughts:
[INDENT] First, thanks, gmitchell, good stuff! You’re the best!!
[/INDENT][INDENT] Second, especially since I hate to see any angry red faces, there is this not-so-pretty work-around if you really, really want to control your timers directly from groov and can’t wait.
Third and however, consider leveraging the intelligence at the I/O level by using a command like Start On-Pulse instead of the timer. Because, while the excellent suggestion with the timer helps with the connection between groov and the controller, if you don’t happen to be using a SNAP-PAC-R, you may have an issue if that “turn off” command gets lost if/when the connection between the controller and I/O goes down.
[/INDENT]Speaking of Intelligent I/O, we have a new white paper that talks about this topic (and a few other related topics). Check out Form 2119, The Case for Intelligent Remote I/O, AKA: “I/O, I/O, it’s off to work we go…” 
Har! Sorry, couldn’t resist. Now off I go…
-Mary
Thanks to everyone, and Ben I’ll keep an eye out for that email.
