LabVIEW
Problem with com port when streaming data.
I don't have that same Modbus library and don't feel like downloading it, so I just get ??? boxes, but I think I see a likely problem.
You're reading 3 different things each loop, opening and closing the session each time. It's not obvious to me whether you're reading 3 things from the same COM port each time or 3 things from 3 different ports.
Whichever it is, if you "stop the program whilst it is running" it causes problems, you say. There is no mechanism in your code to stop running things on either of the inner 2 loops, so I have to conclude that your method of stopping is pressing the little stop sign button on the toolbar. This is very bad practice. I've heard it best described as "it's like stopping your car by driving it into a tree". It is a hard stop, immediately, and does not do any cleanup, nor does it wait for a loop to finish or any other nice stopping point. So it's likely that when you stop the program, it quite often is in the middle of a communication session, and that somehow jams up the port because it doesn't finish communicating.
So the main thing I would suggest as an immediate change is that you add a conditional terminal to your inner 2 FOR loops, and move the Stop button read to the innermost loop, and then connect it to all 3 stop terminals, and then stop using the little "stop sign" button.
The other suggestion I would make would be to move the "Open session" and "Close session" VIs out of the loop, and just run them once at the start and end. Here's a mock-up of what I mean, using VISA reads:
There are plenty of other things that could be improved but those are the big two that I think could assist with your immediate problem.
The issue with ASRL5::INSTR(1), (2), etc. is that you're not closing the COM ports after using them. Implement an actual "graceful stop" function in your code with a button or something that halts the loop, and make sure VISA Close gets called.
Also, don't open and close in the loop- do it once at the start of the "fast stuff" then ONLY do reads from then on.
Thanks for your suggestions, I will do what you suggest about the stopping routine in the future but as it stands the appearance of ARSL::instr codes in the com port is the only way to get the program running at correct speed. Also unfortunately as you suggested to open the and close the session outside the loop but I am reading four different servers and the server address designation is in the open session vi. There appears to be no way to put it into the read holding register VI so that I could do what you suggest. Well I tried copying and editing that VI but tricky things happen like it requires you to de-link it from the library and then some of the functions dont work.
Anyway I am not sure that is the problem because the program will run at the correct speed (or faster) just not without coercion. here is a picture of the modbus master open serial session vi where the reference to ARSL::instr appears but it is a property node and I dont understand what that it is doing.
@EdHarris wrote:
Thanks for your suggestions, I will do what you suggest about the stopping routine in the future but as it stands the appearance of ARSL::instr codes in the com port is the only way to get the program running at correct speed.
I can't comment on the speed issues, but to clarify my comment, I meant that the number in parentheses comes from not closing the port after using it (leaving it hanging open). Not the existence of ASRL:INSTR itself.
For what it's worth, I see the "extra number" thing happen for ports labeled as COM5/COM10/whatever.
