RE: RPM Calculator with Labview and Pi Pico (Trial Version)

Andrew J — Fri, 27 Oct 2023 10:51:49 GMT

First off, I want to be clear I’m not being critical in any way: LabVIEW is such a different approach to what you may be used to that getting this far in such a short time is a great achievement and you’ve picked an interesting project to start with. Posting responses is always open to interpretation versus being sat with someone so you look them straight in the eyes!

I do want to ask how well this works and maybe give some pointers. It’s hard to follow because of all the sequence structures and local variables. I don’t understand why so many sequence structures as it breaks up the natural dataflow processing that LabVIEW uses; sometimes it has to be done because there’s no other way of controlling the dataflow mechanics needed but so many is a bit of a red flag. Really you need to consider the mechanics of dataflow and controlling the execution that way.

I thought at first that the while loop testing against a value of 3500 would never exit once it got going, but of course it never really starts, it only runs once. The case statement is entered when the read value is less than or equal to 1000 then hits the while loop which exits when the value is less than or equal to 3500 which of course it always is. I guess that means the code does only run when nothing is front of the sensor which is what you want. Sort of: isn’t it only counting whenever something isn’t in front of the sensor which depending on the speed of LabVIEW execution vs speed of rotation could be multiple counts within one ‘gap’. I think the whole timing of this is difficult actually and would need tuning through testing, probably involve testing for gaps and blades. I may well have misunderstood what is happening here.

Your use of local variables is almost guaranteed to cause race conditions, but it isn’t clear in every case what they are tied to. For example you have an indicator timestamp but have created another one called time_stamp so you can have a local variable that isn’t tied to timestamp. Look at image 8; you are updating the indicator and its local variable at the same time with the same value - it’s not necessary because they are the same thing. You have the same thing going on in 7 with all the RPM variable updates. Image 4 is a good example of a race condition: you are using the local variable representation of count, and all three elements in that image are the same thing. So you read count, say value is 5, and 5 travels on the wire towards count and towards the increment (there is actually a +1 function by the way) where it changes to 6 and travels towards count. Which gets there first and is count 5 or 6 at the end? You can’t guarantee the order of execution because of dataflow. I suspect you’ve been lucky and that the 5 reaches count before 6 does because it doesn’t go through the increment but it is just luck.

As much as possible, you have to avoid local and global variables. Sometimes they are needed - I’ve used them - but it’s always a potential source of race conditions in LabVIEW so you need to be really careful where they are read and updated because fundamentally LabVIEW controls the execution sequence, not you; you have to influence this by controlling the flow of data so parts of the code get executed when the data is available. You can see how wacky this looks by running the VI with the data flow switch on (the lightbulb on the menu bar in the debug section) - it’s insightful to see which parts of the code run.

Here are some pointers: take a look at Shift Registers for value updates through repetitions. I can see you are using these for the visa session and error control/indicator on the outer loop. These aren’t necessary actually, and I have the feeling that if an error was raised in one of the SCPI functions it would loop forever. I suppose it does anyway, until Stop is signalled so it isn’t important, just not doing what you think it might be. See if you can rewrite this without local variables or the sequence structures and come back here with questions so we can help.

Can you post the front panel? Video showing it working?

Just to re-iterate, I’m not being critical I think you’ve had a good go on a complex dev tool that I’m assuming is new to you. The challenge was to learn LabVIEW which you are clearly starting to get to grips with. Perhaps someone else will come along and tell me where I’ve misunderstood something myself as I’m new to it as well.