09-23-2015 11:06 AM
Hi,
I want to record data with a high sample rate.
Additional to that i want to open and close valves. The program at the apendix runs fine... but if I activate to many of this serial write commands the programm will break down .... timeout ?!
Is ther a way to make this program stable ?
Or even a better way to send the commands ?
The commands are used as case statements.... so the just need to send once .... i think in the moment iam writing them in every loop ?!
Would be happy about some help.
Thanks a lot
09-23-2015 11:52 AM
@kohlmeise wrote:
Hi,
I want to record data with a high sample rate.
Additional to that i want to open and close valves. The program at the apendix runs fine... but if I activate to many of this serial write commands the programm will break down .... timeout ?!
Is ther a way to make this program stable ?
Or even a better way to send the commands ?
The commands are used as case statements.... so the just need to send once .... i think in the moment iam writing them in every loop ?!
Would be happy about some help.
Thanks a lot
Are the valves supposed to open and close in any particular order? Right now they will open and close in whatever order they want to.
Your data writing to file occurs in the same loop as the valves control, so the whole loop has to wait until it is done writing. Is that a good thing when you are opening and closing vavles?
Don't use the stop sign. Someone once said it's like stopping your car by crashing it into a tree. It works, but probably best not to stop your car like that unless it's an extreme emergency. LabVIEW doesn't clean up after itself if you do that. Open files remain open, resources are not released, that kind of thing. Let dataflow do the job for you.
You have no way of propagating your errors, and I assume you have automatic error handling turned on, so pop-ups will occur if there is an error. Is it a good thing to stop LabVIEW in its tracks to display a pop-up message that won't go away without user intervention - while valves are supposed to open and close? (If the answer is "no" then the correct procedure is NOT to turn off automatic error handling, but to take the basic tutorials to learn how to handle errors aprropriately - and learn a common method of enforing dataflow at the same time.)
Try to keep the block diagram fairly neat. Spaghetti coding is like using random indents in a text-based language. The compiler doesn't care, but if a developer wanted to shoot you for doing that, I'd probably look the other way. 😉 A sure way to know you are producing spaghetti code is to use the cleanup button. If it looks neater, you're producing spaghetti code. 😄
All these sequence structures indicate a desire to enforce dataflow, but the lack of knowledge of how to do it. The LabVIEW tutorials will help here.
I'd have to say that, instead of fixing this code, it might be easier to rewrite it from scratch. Take a look at the tutorials, ask a lot of questions here. We can help you tame this code. 🙂
Tutorials can be found here at the bottom of the page.
09-23-2015 02:42 PM
To add to Bills comments:
- I wouldn't put code to the public with the text constant you wired to the FileSelect expressVI… Even in this English speaking forum a lot of people will understand what you wrote there!
- All those boolean buttons are set to switching behaviour: Once they are TRUE you constantly write commands to the serial port: for each button set to TRUE. In random order - as Bill said you missed DATAFLOW at all…
09-23-2015 03:04 PM
To clarify:
LabVIEW does not clean up after itself after you use the stop sign (abort) NOT after you crash you car into a tree! 😉
09-24-2015 03:18 AM
Hi and thank you very much for the fast respons!!!
Sorry for the bad words in the code .... iam working alone at this project and programming make me want to fight with someone .... as iam alone i fight with my codes 😉 ...
The valves should open and close in no particular order ... they should just react to my button clicks ...
despite the messy coding .. it works even if i control a couple of valves... hence i think its realy a problem of continious writing ....
In order to fix that ill try to use event structures ..... so maybe i will just send data if the button state is changed ?!
ill try this today.... pretty sure to see you later again 😄
best regards
09-24-2015 03:51 AM - edited 09-24-2015 03:52 AM
Hi Kohlmeise ("parus major"),
In order to fix that ill try to use event structures ..... so maybe i will just send data if the button state is changed ?!
The quick(6dirty) fix would be to change the switch behaviour to "Latch…"!
09-24-2015 04:38 AM
Yep I tried that before .... problem i had to double the amount of switches .... So every valve needed a switch to open and close ?!.... But also same timeout error ... I found something that is called polling, which shoud be avoid .... (something far beyond my knowledge, but maybe helpful)
09-24-2015 07:12 AM
Hi kohlmeise,
problem i had to double the amount of switches .... So every valve needed a switch to open and close ?!..
Why do you need two switches per valve?
In your example you either send a command (on TRUE) or you don't send a command (on FALSE)…
09-24-2015 07:54 AM
Next try....
I tried to use the event structure.... like in the picture.... As I understood the event just takes place if the value of the boolean "ventil 1" changes?! So I dont waste my cpu resources as the status is not permanently requested ?! ..... Tell me if iam wrong so far ^^
The case structure again decides if the valve should be opened or closed .... fals = a = closed ; True=A= opened
Now the switch works but my data don´t appear ... did i forget something ?
09-24-2015 08:47 AM - edited 09-24-2015 08:48 AM
Hi kohlmeise,
what's the point of the Case structure? With nearly duplicate code inside?
Try this instead:
the event just takes place if the value of the boolean "ventil 1" changes?!
Yes.
Additionally the event structure waits for an event! You can have as many event cases as you like to use. And you can use the TimeOut event of the event structure…