LabVIEW
new folder
All that can be done is to provide general suggestions like:
As you can see, we can't really provide detailed help if we don't see some code. We're not mind-readers, after all.
- Doing things in parallel.
- Don't open/close connections continuously. Open them at the beginning, and close them at the end.
- Don't open/close files all the time. Either open them at the beginning, and close them at the end, or write data out in large chunks.
- Don't create DAQ tasks each time you loop.
As you can see, we can't really provide detailed help if we don't see some code. We're not mind-readers, after all.
Hi Kim,
does your university have the State Diagram Editor. That would be a good product to use, you already do some of the things achieved by a State Diagram.
You already have some init code before the while loop.
To study StateMachines, the first few slides of this webcast are very interesting
Then I see a '50' value connected to??? that is very bad programming a hidden indicator (I think)
I think it would be easier to store COEFF A and COEFF B as numeric, so you have to do the conversion only once instead of every movement.
The time delay should be connected between sending and receiving of the command.
What is the use of the for-loop with the seuence 'dB values Convection & Calculation' inside it? There is nothing done their that needs to be in a for loop. The auto-indexed array of doubles will be filled with the same value over and over.
Here's an example of the localites mentioned:
What should be done here, is that the controls should be connected directly to the 'Greater?' and 'Smaller' structures.
A few additional pointers:
The sections Webcam section, Reset Warming Section, Clear Data section can run at any given point EVEN BEFORE THE FOR-LOOP, these will run in parallel.
What part of your code is too slow?
Ton
Message Edited by TonP on 01-19-2008 10:12 AM
does your university have the State Diagram Editor. That would be a good product to use, you already do some of the things achieved by a State Diagram.
You already have some init code before the while loop.
To study StateMachines, the first few slides of this webcast are very interesting
Then I see a '50' value connected to??? that is very bad programming a hidden indicator (I think)
I think it would be easier to store COEFF A and COEFF B as numeric, so you have to do the conversion only once instead of every movement.
The time delay should be connected between sending and receiving of the command.
What is the use of the for-loop with the seuence 'dB values Convection & Calculation' inside it? There is nothing done their that needs to be in a for loop. The auto-indexed array of doubles will be filled with the same value over and over.
Here's an example of the localites mentioned:
What should be done here, is that the controls should be connected directly to the 'Greater?' and 'Smaller' structures.
A few additional pointers:
The sections Webcam section, Reset Warming Section, Clear Data section can run at any given point EVEN BEFORE THE FOR-LOOP, these will run in parallel.
What part of your code is too slow?
Ton
Message Edited by TonP on 01-19-2008 10:12 AM
LabVIEW user groep 
OK,
but your for loop runs in less than 1 ms. That means there most likely won't be a change so the array is an array of constants while you do the calculation several times=wasted CPU time.
Yes I mean the section run in parellel however to secure synchronization you need other mechnisms.
Could you give a comment on the code snippet I posted?
Because writing a value to itself is useless, secondly you use a local to read the same value again most likely at the very same moment.
Try read up on data-flow
About the camera I don't have that many experience with Imaq USB but if I recall it wasn't that fast, but you should optimize that in a seperate VI and later implement it in the main VI.
Ton
Message Edited by TonP on 01-19-2008 04:41 PM
but your for loop runs in less than 1 ms. That means there most likely won't be a change so the array is an array of constants while you do the calculation several times=wasted CPU time.
Yes I mean the section run in parellel however to secure synchronization you need other mechnisms.
Could you give a comment on the code snippet I posted?
Because writing a value to itself is useless, secondly you use a local to read the same value again most likely at the very same moment.
Try read up on data-flow
About the camera I don't have that many experience with Imaq USB but if I recall it wasn't that fast, but you should optimize that in a seperate VI and later implement it in the main VI.
Ton
Message Edited by TonP on 01-19-2008 04:41 PM
kim515 said
In case 1, there is no connection between the TCP Write and the Time Delay. This means you cannot predict which one will execute first. This is how you've coded it up. In case 2, the TCP Write cannot execute until it has received data on the error wire, which comes from the Time Delay. This means the TCP Write will execute after the Time Delay. In case 3 the Time Delay cannot execute until it has received data on the error wire, which comes from the TCP Write. This means the Time Delay will execute after the TCP Write. This is the case you want.
kim515 said
Ton's question regarding the 'dB values Convection & Calculation' loop is valid. This loop makes no sense, especially since it has a while loop inside it! The conversion itself does not require a for-loop. Also, your explanation of how you're doing the conversion is confusing.
kim515 said
kim515 said
Message Edited by smercurio_fc on 01-21-2008 10:06 AM
As Ton indicated, "the time delay should be connected between sending and receiving of the command". This means you have to use the error cluster to enforce execution order. This, again, stems from a lack of understanding dataflow. Take the following cases:
The "Time Delay" use to give time for the feedback of the machine. If there is not time delay, the result s incorrect. By my learning, Must the "time delay" connect to the command? or Just put inside the squence frame is OK?
In case 1, there is no connection between the TCP Write and the Time Delay. This means you cannot predict which one will execute first. This is how you've coded it up. In case 2, the TCP Write cannot execute until it has received data on the error wire, which comes from the Time Delay. This means the TCP Write will execute after the Time Delay. In case 3 the Time Delay cannot execute until it has received data on the error wire, which comes from the TCP Write. This means the Time Delay will execute after the TCP Write. This is the case you want.
kim515 said
You are actually converting them from a string to a number each time in the loop, which is Ton's point. Also, they don't change after you've read them, so there's no point in reading the value through a local variable, because the value doesn't change until the next time you perform a TCP Write.
Yes. Coeff A & Coeff B is easy to store because they are constant.However, I just need to convert only once.
My program is a REAL TIME monitoring system so there are some coefficient are constant and some are changing every second. I need to convert then with while/for loop.
Ton's question regarding the 'dB values Convection & Calculation' loop is valid. This loop makes no sense, especially since it has a while loop inside it! The conversion itself does not require a for-loop. Also, your explanation of how you're doing the conversion is confusing.
kim515 said
All jokes aside, Ton's point is an important one, as it reiterates the point about understanding dataflow, which is clear you do not.
With the code snippet you posted, It is unless and It just for GOOD LOOK. ^^!!
kim515 said
If I had a nickel for everytime I heard that, and it actually happened, I would be retired and living in luxury already.
I will correct it later.
Message Edited by smercurio_fc on 01-21-2008 10:06 AM
