02-17-2017 03:31 PM
@JÞB wrote:
For the first, a 0 iteration for loop outputs default data ftor the type of any output tunnels.
You get the same with a case that uses output tunnels that are set to use default if unwired. (but that was not available many (many!) versions ago. How old is this code?)
The ">" construct on the button labeled "Zero" probably means that the mechanical action is not latch. Thus the need for detecing a FALSE>TRUE transition. The incorrect latch action could mean that there are local variables and value properties elsewhere.
And yes, the "AND TRUE" is of course a noop, just returning the other input inchanged.
It is difficult to judge code from two small cropped sections and verbal descriptions. If you think we could contribute with more tips, feel free to post some of the VIs.
02-17-2017 03:51 PM
@markconigliaro wrote:
Being new though, I have to ask is there something I'm missing? Are these old school techniques or is there actually some purpose to these that I'm missing?
The person who developed the code was either a bad programmer, or far too inexperienced for the task. I'm not saying all programmers who use 1 iteration loops are bad, there are reasons (few and likely not this case but still). But if you are and'ing a boolean to a constant...then you need to take CS 101, or Digitals 101, or a high school electronics or computer class. Anyway feel proud of yourself being able to recognize code smell.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
02-17-2017 04:41 PM
It's nice to know I'm not crazy. I'll be back in the office on Tuesday, where I'll post a bigger sample of some loops that have a bunch of these kinds of things combined.
I can say some things from memory though. Jeff, the for loops have no outputs. They're all just a single iteration for loop that generates a number or turns something on/off. And altenbach, all buttons are set to "switch until released", and I can't post "some of the VIs" because it's 1 huge, massive VI with no subVI's at all! I don't think a 60 inch TV/monitor would be able to show the whole thing.
02-18-2017 04:30 AM
@Hooovahh wrote:
@markconigliaro wrote:
Being new though, I have to ask is there something I'm missing? Are these old school techniques or is there actually some purpose to these that I'm missing?
The person who developed the code was either a bad programmer, or far too inexperienced for the task. I'm not saying all programmers who use 1 iteration loops are bad, there are reasons (few and likely not this case but still). But if you are and'ing a boolean to a constant...then you need to take CS 101, or Digitals 101, or a high school electronics or computer class. Anyway feel proud of yourself being able to recognize code smell.
I have to commit that I sometimes use the 'and with a boolean constant.
In cases where you want to debug some code and you have a Init/Firstrun input , the 'AND with boolean constant' is a nice way to overrule that input. After debugging one could have deleted it , but simply leave the constant TRUE usually doesn't hurt.
02-19-2017 11:12 AM
One plausible reason that someone put in an AND TRUE is that they were ANDing with some other condition in the past. Perhaps they need to force that to be true while debugging or modifying their logic. Eventually, they got to a point where they never needed to put the other logic back in, but never got around to stripping that out and now it is just an artifact left over from previous code.
02-20-2017 07:25 AM - edited 02-20-2017 07:26 AM
In cases like those I usually use a disabled diagram structure, and have a case where there is a true constant, I might then put the #debug bookmark in the case as well. If you did choose to do it your way you could still place a code comment stating what you are doing and it would justify the odd looking bit logic.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
02-20-2017 09:19 AM
I ran into this one in some legacy code I inherited. It was to convert data coming back from Modbus into floating point...
02-20-2017 09:40 AM
@BowenM wrote:
I ran into this one in some legacy code I inherited. It was to convert data coming back from Modbus into floating point...
Careful. Notice that the 0 index was not used. So you need to delete that element before you rotate.
02-20-2017 10:06 AM - edited 02-20-2017 10:06 AM
@crossrulz wrote:
Careful. Notice that the 0 index was not used. So you need to delete that element before you rotate.
You are correct, sir.
The lower snip came from my code. I'm using a newer Modbus package. The old one returned an array of u8 with element 0 being the number of bytes per data point.
The new one just returns an array of u16. I should have modified it to be identical before posting though 🙂
02-20-2017 10:13 AM
BowenM wrote:
The lower snip came from my code. I'm using a newer Modbus package. The old one returned an array of u8 with element 0 being the number of bytes per data point.
The new one just returns an array of u16. I should have modified it to be identical before posting though 🙂
If you have an array of U16, then you only rotate 1 element. Or you could use Reverse 1D Array.