03-16-2012 09:50 AM - edited 03-16-2012 09:53 AM
03-16-2012 10:02 AM
I used the Advanced Serial Write and Read vi from labview examples to open the port and then added my code you see on the screen shot. I increased the timeout to like 10 seconds, the responses from my controller dont take anywhere near that amount of time.
03-16-2012 10:25 AM
The issue here may even not be related to the configuration of the serial port since we have no idea of what else is going on in you program. When you use the hyperterminal with the configuration parameters used in your program you said it works. My suggestion of creating a small vi with just the comm part of your program could be helpfull.
Saying you used the Advanced Serial Write and Read vi doesn't show us how and where you used these vi. So far your not giving us that much information to help us help you. Why don't you post your vi?
Ben64
03-16-2012 10:41 AM
Not wiring up the error wire is not solving the problem. You are just ignoring it.
It doesn't make sense to me how you could be getting a timeout error, still getting your data, and that removing the error wire is allowing it to work and not giving you a more intrusive pop up message about the error. (You didn't disable automatic error handling in the VI did you?)
Are you sure the termination character is the same for the data going out as it is for the data going in?
Are you sure it is carriage return? It very well could be, but I find the line feed character is often used more.
03-16-2012 12:13 PM - edited 03-16-2012 12:17 PM
@ben64 wrote:
The issue here may even not be related to the configuration of the serial port since we have no idea of what else is going on in you program. When you use the hyperterminal with the configuration parameters used in your program you said it works. My suggestion of creating a small vi with just the comm part of your program could be helpfull.
Saying you used the Advanced Serial Write and Read vi doesn't show us how and where you used these vi. So far your not giving us that much information to help us help you. Why don't you post your vi?
Ben64
Well my comm part is exactly the same as the "Advanced Serial Write and Read" VI, i just changed the termination character. Anyway my code is posted.
Re:Ravensfan
I did disable the auto error handler.
Are you sure the termination character is the same for the data going out as it is for the data going in?
Yes because the controller wont process the commands it recieves if they arent terminated with a carriage return and all the controllers responses are also terminated with a carriage return(I worte the C code and verified this in the C debugger)
Are you sure it is carriage return? It very well could be, but I find the line feed character is often used more.
Yes, that is how i wrote the controllers software.
03-16-2012 01:04 PM
As I and someone else has told you, put your termination character for the command going out in the string you are writing. Don't use that ASRL termination character method that the Advanced Serial WriteRead uses. Make the termination character apart of the string command you are writing to the serial port. Remove the buffer size setting and the XON/XOFF character settings as well.
Do not disable automatic error handling. Turn it back on.
Wire up the error wire through the VISA Read again.
Do not use all of those local variables. I don't think you have a race condition happening, but even so, many of those local variables can be eliminated. For instance, you are using multiple copies of Controller Address in that case structure. Move the control terminal out of the case structure and wire it to the case structure. Then you can just use that tunnel in whatever cases need the Controller Address thus eliminating the local variable.
Put a small wait statement in the while loop where you are polling to see if any bytes are at the port so you don't consume all CPU resources on that one operation. Actually, since you are using a termination character, there is really no need for that while loop at all.
It looks like you've increased your timeout setting, but I would increase it further to at least 1000 or 2000 milliseconds.
Put some error indicators or probes on the error wires going into and out of the VISA Read. Let's really make sure of the error you are getting.
Run the VI and if you get an error, take a screenshot so that we can see the data in the Read string and the error indicators or probes.
03-16-2012 02:36 PM - edited 03-16-2012 02:36 PM
@Ravens Fan wrote:
As I and someone else has told you, put your termination character for the command going out in the string you are writing. Don't use that ASRL termination character method that the Advanced Serial WriteRead uses. Make the termination character apart of the string command you are writing to the serial port. Remove the buffer size setting and the XON/XOFF character settings as well.
Do not disable automatic error handling. Turn it back on.
Wire up the error wire through the VISA Read again.
Do not use all of those local variables. I don't think you have a race condition happening, but even so, many of those local variables can be eliminated. For instance, you are using multiple copies of Controller Address in that case structure. Move the control terminal out of the case structure and wire it to the case structure. Then you can just use that tunnel in whatever cases need the Controller Address thus eliminating the local variable.
Put a small wait statement in the while loop where you are polling to see if any bytes are at the port so you don't consume all CPU resources on that one operation. Actually, since you are using a termination character, there is really no need for that while loop at all.
It looks like you've increased your timeout setting, but I would increase it further to at least 1000 or 2000 milliseconds.
Put some error indicators or probes on the error wires going into and out of the VISA Read. Let's really make sure of the error you are getting.
Run the VI and if you get an error, take a screenshot so that we can see the data in the Read string and the error indicators or probes.
Good tips, but i still get the error. Im just gonna give up on this one and not wire the error terminals. The program works great if I do this. I will never know what caused the error. Thanks for everyones help.
03-16-2012 02:49 PM
LM84 wrote:Good tips, but i still get the error. Im just gonna give up on this one and not wire the error terminals. The program works great if I do this. I will never know what caused the error. Thanks for everyones help.
Really?
Don't give up you are falling into a very bad habit and you will never know how to correctly deal with these issues.
Take the time, clean up you code, and figure it out. Believe me this WILL happen again.
03-16-2012 02:58 PM
I'm glad we could help. And I feel we could help a bit more if you did a few of the other things such as post a screen shot showing the data and the errors.
You've given us a lot of information, but much of it seems to be conflicting. I've done a lot of work with serial devices, and they really aren't that complicated in the end. When there are problems, it is usually wiring, port settings, or problems parsing/analyzing the data. For you to have something that works, but gives an error, so you hide and ignore the error to allow it to work, is just not right and doesn't need to be. There is just some key missing piece of information there that could explain the conflicting information. And once we know that and fix it, then your application should be able to work reliably without having to hide and ignore an error.
03-16-2012 03:36 PM
I connected the "Bytes at Port" indicator to the VISA "bytes to read" terminal and it worked!....no error!
Does this mean my timeout error was due to VISA trying to read too many bytes?..I had the "bytes to read" set to 1000(the default). I thought this value wouldnt matter since the VISA would stop reading when it encountered the CR, does this imply that my controller is not sending a carriage return?. Anyway im glad its working now.