LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error 85; Scan From String (arg 1)

the background is that: I am developing a vi to control signal generator and power amplifier to get the power that I need. It's like making a+b=c. C is the power I need at different frequencies, a is the output of sig gen, and b is the gain of amplifier.

 

The vi will adjust the a and b under certain ranges until it finds suitable a and b (while loop). Then it will move forward until all the frequencies are done (for loop).

 

The sig gen and amplifier are initialized at the beginning the for loop, and closed at the end of the for loop, which means that during the entire program they will open and close one time each.

 

It works fine with certain c set and all instruments shut down after finishing, but somehow once it stops at some point and reports that:

 

"error 85; Scan From String (arg 1) in AR Amplifier.lvlib:AR Amp.lvclass:Read Fault.vi."

 

The error message was captured by the close.vi. I commend it to shut down the power before close.vi, but in reality, the amplifier which reports fault keeps running and the sig gen which works fine shuts down normally, which means that the error bypasses my command.

 

Capture.PNG

here I upload a simplified version of my vi for us to discuss. 

0 Kudos
Message 1 of 15
(782 Views)

You need to do some troubleshooting.

 

The LabVIEW error code is saying that the scan from string function in the Read Fault.VI is failing because it is not receiving data in the expected format. It looks like you are sending the command "FSTA?" which should return the fault status formatted as "FSTA= 00xx" where xx is the hex code of a fault. Probe the wire coming out of the "Send Command.VI" inside of the "Read Fault.vi" and see what data is actually coming out. Like so -

 

Wire Probe.jpg

 

If the response is not "FSTA= 00xx" then the scan from string will return an error.

 

 

0 Kudos
Message 2 of 15
(750 Views)

Wow. Thanks for your patience.

 

Probing seems to be a good way to check. Ah, last time this random mistake took me 2.5 hrs to capture it. I will check next Monday.

 

Since this whole program is copied from AR example program, so I take a look into the vi before this scan from string.vi, which is the send command.vi made by ar the company this time. I find out that the logic of it has a potential issue:

 

The "error in" cluster from read fault.vi doesn't connect to the send command.vi. It seems that in default the send command.vi will consider there's no error in. Then it can generate a correct string for scan from string.vi. 

 

Capture.PNG

 

if somehow the error in of send command.vi changes to that error is found, it will give no output to response, which leads to the fault of scan from string.vi.

Capture1.PNG

 

so maybe I can try to connect the "error in" from read fault.vi to send command.vi to make the state of it clearer than just hanging.

 

Capture2.PNG

0 Kudos
Message 3 of 15
(691 Views)

it seems reasonable to explain for the random mistake of this case. oh maybe I forget to mention that the error 85 of this case happened 2 times at different conditions.

 

anyway, just a thought and can only be examined next Monday.

 

let's see whether you agree with this possibility. or other brainstorming ideas you may have. thanks.

 

0 Kudos
Message 4 of 15
(692 Views)

The error handling of the AR library is fine. If there is an error coming in then the "Error" case will execute, passing the error through and not performing any action. Similarly, if there is an error coming out of the "Send Command.VI", the scan from string function will also pass the error through without doing any logic. The error you described is originating from the scan from string function, there is no error before that. I don't see any logic errors and it seems that for some reason the device is either giving a bad response, or there is a communication error. If capturing that error is rare you could add some code that looks for an error just after the scan from string function and log the actual response. There is also the NI IO Trace program which can log all the communication going on.

0 Kudos
Message 5 of 15
(677 Views)

Let me explain it again.

 

the original read fault.vi doesn’t seem to deliver the error in cluster to send command.vi by wiring. So yes there’s no error before read fault.vi then it would use scan command.vi.

 

But for scan command.vi, it’s error in port is hanging there, right? I am wondering if the hanging state would trigger random state so that there’s no error before read fault but scan command side considers it has. Or the rule is that hanging there would keep the state as no error?

0 Kudos
Message 6 of 15
(671 Views)

Tony@NTU wrote:

. Or the rule is that hanging there would keep the state as no error?

 


 Yes, generally speaking unwired error in terminals are treated as no error. It is an optional input (although generally considered good practice to wire it). When VI's or functions have required inputs, the VI containing it will have a broken arrow if it is not wired.

0 Kudos
Message 7 of 15
(664 Views)

Ah, I got your point now.

 

It seems that there should not an error before scan from string.vi since the error message indicates it's the error in scan from string.vi.

 

My assumption as listed before is that send command.vi sends empty command somehow because of the hanging error in port and that may cause this random failure.

 

Another fact we can look at, it's that the error message is sent through close.vi but not directly stop and highlight the read fault.vi as other error does. It may indicate something. 

0 Kudos
Message 8 of 15
(661 Views)

Tony@NTU wrote:

Ah, I got your point now.

 

It seems that there should not an error before scan from string.vi since the error message indicates it's the error in scan from string.vi.

 

My assumption as listed before is that send command.vi sends empty command somehow because of the hanging error in port and that may cause this random failure.

Left unwired the "Send Command.vi" will use the default value of "Error In", which is no error. This will always be the case, it is not random.

 

 

 

 

Another fact we can look at, it's that the error message is sent through close.vi but not directly stop and highlight the read fault.vi as other error does. It may indicate something. 


I think you are talking about when an error occurs in other parts of your project/vi, execution stops and highlights where the error occurred. This is an option in LabVIEW.

Automatic error handling.jpg

 

With this checked, the stop and highlight event you see will happen. However, wired out error clusters will disable this automatic error handling.

 

"By default, LabVIEW automatically handles any error when a VI runs by suspending execution, highlighting the subVI or function where the error occurred, and displaying an error dialog box.

To disable automatic error handling for the current VI, select File»VI Properties and select Execution from the Category pull-down menu. To disable automatic error handling for any new, blank VIs you create, select Tools»Options and select Block Diagram from the Category list. To disable automatic error handling for a subVI or function within a VI, wire its error out parameter to the error in parameter of another subVI or function or to an error out indicator."

 

- from https://www.ni.com/getting-started/labview-basics/handling-errors 

 

This is the reason the error was not treated the same as other errors that you may have encountered without the error out cluster wired.

 

0 Kudos
Message 9 of 15
(647 Views)

thanks.

 

I got the probing results this time. it indicates a communication error.

 

Capture1.PNG

0 Kudos
Message 10 of 15
(552 Views)