07-17-2018 03:06 AM
Hello you people much smarter than me,
I am currently working on a project where a system is controlled by receiving strings via RS232. The system is going to control some stepper motors, with a varying angle of movement.
I made myself a little GUI with LabVIEW for ease of use, but I am now presented with a minor issue (not even a bug). I have a dial to set the step angle and then a button to select the direction. The buttons trigger an event change within a while loop, the step angle is "coming in from the outside". The issue is now that whenever I change the angle, the new value is not transmitted on the next move, but the one after that. While this is supposed to happen as the loop runs only if I have an event change, it is still annoying because you always have to think one step ahead.
Is there a way to change this, or am I maybe missing a simple thing how this is to be mended?
I am a relative beginner/ occasional user of LabVIEW btw.
I attached my VI (LabVIEW '18) if you want to have a look yourselves.
Thanks,
Ivo
Solved! Go to Solution.
07-17-2018 03:31 AM
Hi Perl,
the step angle is "coming in from the outside". … the new value is not transmitted on the next move, but the one after that.
A clear THINK DATAFLOW! problem combined with a race condition…
When you need the current value IN THE EVENT CASE you need to read that value IN THE EVENT CASE. THINK DATAFLOW!
07-17-2018 03:37 AM
Wouldn't I need 4 front panel items for the different directions then?
I would like only one single readout, that is used by the 4 different events.
The issue is to minimize user error, and in this case, the bigger issue is that the angle for all 4 directions is the same.
If I could "join" the 4 elements in the block diagram in one readout on the front panel, that would be fantastic.
07-17-2018 03:38 AM - edited 07-17-2018 03:39 AM
Hi Perl,
I would like only one single readout, that is used by the 4 different events.
You could:
- read from a local inside those event cases
- read the dial control in it's own event and store it's value in a shift register…
07-17-2018 03:45 AM
Thanks, I will try that.
On another note, is it possible to tell a numeric control wheter to use a point or comma as decimal point?
It currently does a comma, and a point would definitely be better to treat in C++ i my system.
07-17-2018 03:57 AM
Hi Perl,
you can:
1. Set your OS to use the point instead of the comma as decimal separator.
2. Tell LabVIEW not to use the system setting, but the point by default.
3. When communicating with your "C++ system" you can format your numeric value into string using FormatIntoString with proper format codes…
07-17-2018 03:58 AM
@GerdW
you can:
2. Tell LabVIEW not to use the system setting, but the point by default.
How would one do that?
07-17-2018 05:10 AM - edited 07-17-2018 05:12 AM
07-17-2018 05:25 AM
Alright, got it.
Thanks, Mate
03-21-2021 12:51 PM - edited 03-21-2021 12:53 PM
@Perlmarmelade wrote:
Wouldn't I need 4 front panel items for the different directions then?
The correct way would be to eliminate all this duplicate code!!!
Once you combine all four direction events into one, they all can read the same value from the same terminal inside the same event. Here's how that could look like.
Now you have less code which is also much easier to maintain. For example if you later decide that you actually want two decimal digits, you only need to make one simple change instead modifying in four different places!
Many of your other events only differ e.g. by a single string (stop, end, origin, reset) and they could be combined in a similar way (not shown).