09-14-2020 04:29 AM
Dear all,
So the real code is of course more than this, but basically - can I do this (safely?) in a SCTL?
This will sit in a SCTL on a shift register (in the "Wait with CONVST Low" case), and I'll unbundle (via accessor) the "Next State" at the beginning of the SCTL and then pass that to the case structure.
Basically the same code already exists using a combination of shift registers, so I'm hopeful that this is fine, but some brief crisis of (non)confidence has overtaken me and I want to check that reading and writing the same value (Wait Remaining, in this example) in a SCTL isn't going to lead to unexpected behaviour due to a race condition here.
The motivation is to move more complicated logic into a nicer abstraction and prevent the addition of another half a dozen shift registers to my SCTL to handle more complicated situations than this one, but they have basically the same code - unbundle, check some things, add/subtract etc, bundle the new values for those elements.
Solved! Go to Solution.
09-14-2020 04:39 AM
Updating the same value (Wait Remaining) in the way you have developed will not be creating any race condition since it works sequential.
09-14-2020 06:48 AM
Encapsulation, one of the benefits using OOP, the data belongs to a class, you can't unbundle or access the data outside the class without your consentment or by using accessors.
09-14-2020 07:06 AM
When compiled to the fabric, almost all of that (the unbundle and bundle) are just wires, eventually going to a holding register. So I see no dangers in this code from being in a SCTL.
09-14-2020 07:14 AM
I'd always use <=0 for the compare, not =0.
What if the class data is somehow reset (forgot to wire a tunnel)? Or if some other (future) function decreases the Wait Remaining or sets it to 0 (if it's done waiting). The Wait Remaining will probably become 0... Then you get 0-1=-1, and =0 will fail. You'll be waiting very, very long.
There'd be no race condition, unless there's a serious bug in LabVIEW.
09-14-2020 07:16 AM