01-26-2018 04:49 PM
enthusiast4 wrote:PS:Below is the attached VI . Check only the State 2.
I had a quick look at your code and there are many very questionable parts.
There is huge amounts of duplicate code. For example in state 1 and 2 you create a gigantic 2D array of 6000 empty waveforms. Wouldn't once before the main loop be sufficient? (I currently don't have IMAQ installed, so I cannot tell why you are doing that). Since you are later autoindexing on the next FOR loop input, all you actually need is an array of three waveforms and not autoindex later, right?
State 1 and 2 differ only by a few minor items. Couldn't you re-use most of the code?
To unflatten something from a string to a string, there is no need to wire a string local variable to the type input. A simple empty string constant would suffice. (I am not even sure why you are doing all that! Do you understand what unflatten actually does?)
It is a really bad idea to hide multiple event structures deep inside different cases of a case structures. Since all events are set to lock the panel until the event completes, operating certain controls in the wrong order could deadlock the entire program.
Virtually none of your local variables are needed if you would place the terminal in a convenient place and branch the wire. Somehow, I get the feeling that you could get the same functionality with 20% of the code amount.
01-27-2018 02:04 AM
@altenbach wrote:
enthusiast4 wrote:PS:Below is the attached VI . Check only the State 2.
I had a quick look at your code and there are many very questionable parts.
There is huge amounts of duplicate code. For example in state 1 and 2 you create a gigantic 2D array of 6000 empty waveforms. Wouldn't once before the main loop be sufficient? (I currently don't have IMAQ installed, so I cannot tell why you are doing that). Since you are later autoindexing on the next FOR loop input, all you actually need is an array of three waveforms and not autoindex later, right?
State 1 and 2 differ only by a few minor items. Couldn't you re-use most of the code?
To unflatten something from a string to a string, there is no need to wire a string local variable to the type input. A simple empty string constant would suffice. (I am not even sure why you are doing all that! Do you understand what unflatten actually does?)
It is a really bad idea to hide multiple event structures deep inside different cases of a case structures. Since all events are set to lock the panel until the event completes, operating certain controls in the wrong order could deadlock the entire program.
Virtually none of your local variables are needed if you would place the terminal in a convenient place and branch the wire. Somehow, I get the feeling that you could get the same functionality with 20% of the code amount.
I agree what you said. I know my code is not efficient. I will make improve it later. I am concerned right now about the State 2 problem.
I have managed to make the slider as indicator from 201-500 i.e the slider moves from 201 till 500 when AVI is played for those particular frames. But, later the slider should act as a control such that the user can move the slider from 500 to back till 201 and should be able to check the timestamps for those frame numbers. So, once the slider as indicator reaches 500 th frame number, then the user should be able to control the slider to check the timestamps.
Currently, I am not able to move the slider to check the time stamps after it goes till the end frame 500. It throws an error: Invalid frame number in AVI Read VI
01-28-2018 11:52 AM - edited 01-28-2018 11:52 AM
Hi enthusiast,
So, once the slider as indicator reaches 500 th frame number, then the user should be able to control the slider to check the timestamps.
Quite simple:
According to your requirement…
Currently, I am not able to move the slider to check the time stamps after it goes till the end frame 500. It throws an error: Invalid frame number in AVI Read VI
When "it throws an error" then you need to implement better error handling as well as better UI input handling!
Why do you even allow invalid frame numbers?
01-28-2018 09:52 PM
You appear to be using the deprecated AVI functions instead of the AVI2 functions, which directly support Frame numbers. I'm not 100% certain I understand your question ...
This is the AVI2 Read Frame function:
Bob Schor
01-29-2018 01:06 AM
01-29-2018 04:36 AM
@Bob_Schor wrote:
You appear to be using the deprecated AVI functions instead of the AVI2 functions, which directly support Frame numbers. I'm not 100% certain I understand your question ...
This is the AVI2 Read Frame function:
Bob Schor
I am using AVI instead of AVI2 because only with AVI Write VI, I have the direct option (terminal: data in AVI Write) for writing image to the user created AVI file along with the timestamps. Once, I have written the corresponging images to the AVI file, I want to read those images from the created AVI file such that the slider shows the timestamps for each Image.
01-29-2018 05:08 AM
@GerdW wrote:
Hi enthusiast,
So, once the slider as indicator reaches 500 th frame number, then the user should be able to control the slider to check the timestamps.
Quite simple:
According to your requirement…
Currently, I am not able to move the slider to check the time stamps after it goes till the end frame 500. It throws an error: Invalid frame number in AVI Read VI
When "it throws an error" then you need to implement better error handling as well as better UI input handling!
Why do you even allow invalid frame numbers?
Thanks for the insight. Finally, I got to know my mistake. After writing images in the user created AVI file along with the timestamps, the total number of Frames written whhere 300 i.e 0-299. Instead of reading only the 300 Frames (along with the timestamps) in the AVI read , I was making a mistake of reading 500 Frames,which was a blunder. Finally, I rectified it by substracting the total end frames i.e 500 as shown in the slider indicator from the start Frame i.e 201. Finally, it gives a total of 300 Frames to the AVI Read to read those 300 Frames.