LabVIEW
A strange question when configuring a Gige camera with IMAQdx.
As mentioned before this indicates a timing problem of the camera. You need to place some delay either between opening the camera and setting the property of between setting the property and first trying to grab a picture or maybe even both.
Recently, I encountered the same problem in a labview program for GPS as shown below. I solved this question by inserting a time delay module before the .net property node. So, I believe such a question comes from the property module rather than the IMAQ modules.
@morningmaple wrote:
Recently, I encountered the same problem in a labview program for GPS as shown below. I solved this question by inserting a time delay module before the .net property node. So, I believe such a question comes from the property module rather than the IMAQ modules.
The signal moise ratio of this post is pretty low. The OP’s problem was indeed IMAQ but more specifically the camera. Yours is VISA and not .Net. The problem in both cases appears to be with the external device connected to the respective interface. And that’s not very strange. External devices are often many magnitudes slower than a modern Intel Core based computer. So it’s very possible that you simply overrun the device when you try to do things to fast.
Especially since you use the Bytes at Serial Port property, which as I have stated in many other posts here on this forum, really has absolutely NO business of even being present in 100% of instrument control software.It's not the right thing to use in every single instance of a VI that is meant to talk to an instrument for automation control since it makes the whole communication completely dependent on the execution speed inside your computer, which is what you want to avoid at all cost.
If you talk to an instrument you either receive a fixed sized amount of data back, either as complete message or a header that contains the amount of data that is to follow, but in most cases you receive an answer that is terminated by a special character, most often a carriage return or line feed. VISA provides the means to let the VISA Read function terminate on such a character and your Initial Serial Port VI that you use in your code even configures the serial port to use this feature with the line feed character by default. But you can reconfigure that through the "termination char" input. With that enabled you simply need to pass a big enough number of characters to read to the VISA Read function that is guaranteed to be bigger than the longest expected answer, et voila: VISA Read will then sit and wait there until one of four things happens:
1) a VISA error has occurred somewhere in the driver, which is then returned
2) The specified timeout has occurred, returning a timeout error
3) the amount of data you requested has arrived, returning a warning that you received the expected amount of data and there might still be more present in the input buffer
4) the specified termination character has been encounterd in the data stream
Et voile, no Bytes at Serial Port necessary at all as long as the device responds in the time you specified as read timout to the VISA Read.
But other than the race condition introduced here by the use of the Bytes at Serial Port property, it hasn't a lot to do with the original problem in this thread.
@rolfk wrote:To be honest, I have learned a lot from you and thank you so much.
Actually, the posted question has been resolved by adding the time delay module based on your suggestion. However, I had to add it in front the property module.
Also, our camera is 12-bit camera similar to CCD. This is why only half of image appeared as I mentioned in the former posts.Could you please give some advice on how to log 12-bit images? Thanks in advance.
@morningmaple wrote:
Recently, I encountered the same problem in a labview program for GPS as shown below. I solved this question by inserting a time delay module before the .net property node. So, I believe such a question comes from the property module rather than the IMAQ modules.
The signal moise ratio of this post is pretty low. The OP’s problem was indeed IMAQ but more specifically the camera. Yours is VISA and not .Net. The problem in both cases appears to be with the external device connected to the respective interface. And that’s not very strange. External devices are often many magnitudes slower than a modern Intel Core based computer. So it’s very possible that you simply overrun the device when you try to do things to fast.
Especially since you use the Bytes at Serial Port property, which as I have stated in many other posts here on this forum, really has absolutely NO business of even being present in 100% of instrument control software.It's not the right thing to use in every single instance of a VI that is meant to talk to an instrument for automation control since it makes the whole communication completely dependent on the execution speed inside your computer, which is what you want to avoid at all cost.
If you talk to an instrument you either receive a fixed sized amount of data back, either as complete message or a header that contains the amount of data that is to follow, but in most cases you receive an answer that is terminated by a special character, most often a carriage return or line feed. VISA provides the means to let the VISA Read function terminate on such a character and your Initial Serial Port VI that you use in your code even configures the serial port to use this feature with the line feed character by default. But you can reconfigure that through the "termination char" input. With that enabled you simply need to pass a big enough number of characters to read to the VISA Read function that is guaranteed to be bigger than the longest expected answer, et voila: VISA Read will then sit and wait there until one of four things happens:
1) a VISA error has occurred somewhere in the driver, which is then returned
2) The specified timeout has occurred, returning a timeout error
3) the amount of data you requested has arrived, returning a warning that you received the expected amount of data and there might still be more present in the input buffer
4) the specified termination character has been encounterd in the data stream
Et voile, no Bytes at Serial Port necessary at all as long as the device responds in the time you specified as read timout to the VISA Read.
But other than the race condition introduced here by the use of the Bytes at Serial Port property, it hasn't a lot to do with the original problem in this thread.
@rolfk wrote:
@morningmaple wrote:
Recently, I encountered the same problem in a labview program for GPS as shown below. I solved this question by inserting a time delay module before the .net property node. So, I believe such a question comes from the property module rather than the IMAQ modules.
The signal moise ratio of this post is pretty low. The OP’s problem was indeed IMAQ but more specifically the camera. Yours is VISA and not .Net. The problem in both cases appears to be with the external device connected to the respective interface. And that’s not very strange. External devices are often many magnitudes slower than a modern Intel Core based computer. So it’s very possible that you simply overrun the device when you try to do things to fast.
Especially since you use the Bytes at Serial Port property, which as I have stated in many other posts here on this forum, really has absolutely NO business of even being present in 100% of instrument control software.It's not the right thing to use in every single instance of a VI that is meant to talk to an instrument for automation control since it makes the whole communication completely dependent on the execution speed inside your computer, which is what you want to avoid at all cost.
If you talk to an instrument you either receive a fixed sized amount of data back, either as complete message or a header that contains the amount of data that is to follow, but in most cases you receive an answer that is terminated by a special character, most often a carriage return or line feed. VISA provides the means to let the VISA Read function terminate on such a character and your Initial Serial Port VI that you use in your code even configures the serial port to use this feature with the line feed character by default. But you can reconfigure that through the "termination char" input. With that enabled you simply need to pass a big enough number of characters to read to the VISA Read function that is guaranteed to be bigger than the longest expected answer, et voila: VISA Read will then sit and wait there until one of four things happens:
1) a VISA error has occurred somewhere in the driver, which is then returned
2) The specified timeout has occurred, returning a timeout error
3) the amount of data you requested has arrived, returning a warning that you received the expected amount of data and there might still be more present in the input buffer
4) the specified termination character has been encounterd in the data stream
Et voile, no Bytes at Serial Port necessary at all as long as the device responds in the time you specified as read timout to the VISA Read.
But other than the race condition introduced here by the use of the Bytes at Serial Port property, it hasn't a lot to do with the original problem in this thread.
To be honest, I have learned a lot from you and thank you so much.
Actually, the posted question has been resolved by adding the time delay module based on your suggestion. However, I had to add it in front the property module.
Also, our camera is 12-bit camera similar to CCD. This is why only half of image appeared as I mentioned in the former posts.Could you please give some advice on how to log 12-bit images? Thanks in advance.
