So my issue is that I am taking data in intervals based on the time delay. My issue is taking a lot of data points in a short period of time. We know that the device can do it but I am a bit confused in the program where a change needs to be made to be able to do that. As it stands it seems like in each iteration it can take a maximum of 35 points before the timeout of 5000 micro seconds. Is there a way in that timeout period to have it take say 1000 points?Changing the trigger count does not change the number of points it is taking.
My first thought was changing in the block read section changing the number of bytes it can accept, but that did not seem to have an effect on taking more data in that short period of time. So if there is a way I really am unsure how to ramp up the ability of taking points.
The second issue that concerns me if there is a fix to the first problem is the delay. The time delay in there now seems to have about a 5 second increase in delay than it should. So if the delay is set at 15 seconds the times between data points is actually closer to 20 seconds. Is the a way to shorten this extra delay time or minimize it in any way? The next set of readings are for voltage drops and for those the voltage drops are in the microsecond range so having extra delays especially such large ones would be counter productive.
Thanks for any help regarding this.
Are you using a NI-DAQ device?
If so, have you checked the sample rate of your DAQ? The higher is the sample rate, you will be able to get more samples (points) per second.
It is possible that the problem is not in your VI, but in the way you're setting up you hardware.
If you are not using a NI-DAQ device, let us know which device you're using.
Many (most?) of us are not likely to have the Keithley VI's, and thusly most of your VI will have missing VI's.
There's nothing in your loop that would cause an extra 5 seconds. Unless, when you said 5000 micro seconds, you meant 5000 milli-seconds, in which case that's exactly 20 seconds if the Keithley is timing out.
p.s. your Path isn't wired correctly. You just need to supply a path input (preferably from outside the loop) and wire it in. No feedback node.
p.p.s. Same VI and path issues in THIS post.
I did mean milliseconds, sorry my readings have been microamps so i had micro in my head. Here is the block read vi specifically, if you couldnt open it from my main vi. There is a 5000 millisecond timeout I know this. My issue is getting more than 35 values to be taken. So if I set the trigger to something greater than 35 it would take that many points, which is currently is not. The keithley is more than capable of taking thousands of readings in a a very small period of time so that is why I am confused as to why I am being restricted.
Well now were talking about serial ports, and the fact that if the wired number of bytes are no seen, it'll timeout. This is why you should read the bytes at the port (Bytes at Port node). When you have the expected bytes, read them. If you don't get the expected bytes, handle the error.
The ones in there the 32 etc are the default that came with the base of this program which was from Kiethley. How do you check the bytes though? I was a bit confused by your response on how to check the expected bytes.
Something like this, incomplete, but hopefully you get the idea.
Edit: By the way, the Bytes at Port property node is located in the Instrument I/O palette under Serial.
To clarify as is now I have not been timing out, I just want it to be able to take more data points in the given time.
Also regarding the schematic you showed, I am not exactly sure where something like that would go in my vi. From what i can tell that is just to get the number of bytes at the port, correct? How does that help me knowing how many bytes at the port in solving this problem?