DBL error: incorrect position of the decimal point read by the instrument

[isend73]

LabVIEW 2013 (Version 13.0f2 (32-bit)) on Windows 7

The instrument being controlled by LabVIEW often receives a number 10 times smaller than what I input via DBL. For example, I input "0.2" via DBL, but only half of the time the instrument would successfully read "0.2". The other half of the time it would read "0.02". There is even a small chance it would read "0".

A run consists of a few loops. The first two loops always give correct results (i.e., the instrument receives correct numbers), but the success rate seems to decline as the loop count increases. Looks like the memory of the computer or that of the instrument matters?

What can I try to avoid this incorrect behavior? Thank you.

[Blokk]

---

@isend73 wrote:

LabVIEW 2013 (Version 13.0f2 (32-bit)) on Windows 7

The instrument being controlled by LabVIEW often receives a number 10 times smaller than what I input via DBL. For example, I input "0.2" via DBL, but only half of the time the instrument would successfully read "0.2". The other half of the time it would read "0.02". There is even a small chance it would read "0".

A run consists of a few loops. The first two loops always give correct results (i.e., the instrument receives correct numbers), but the success rate seems to decline as the loop count increases. Looks like the memory of the computer or that of the instrument matters?

What can I try to avoid this incorrect behavior? Thank you.

---

You just do not give enough information so we cannot help. Attach your VI which exhibits this problem. You also did not mention the used communication HW/protocol between your PC and your instrument. Is it serial? GPIB? Something else? State the model and manufacturer of the instrument. Do you have a manual for it? Is the required communication protocol explained in this manual.

Just a wild guessing, but a wrongly programmed protocol can cause such issues what you see...

[altenbach]

---

@isend73 wrote:

A run consists of a few loops. The first two loops always give correct results (i.e., the instrument receives correct numbers), but the success rate seems to decline as the loop count increases. Looks like the memory of the computer or that of the instrument matters?

---

As has been said, we need to see some code.

What is a "run"? Why do you have 3+ loops and what do these loops do. It almost sounds they all communicate with the instrument in parallel (since you say that the first two receive correct results). What kind of "communication" do you use (serial, ethernet, etc.). What's the datatype of the control where you enter the 0.2 (dbl numeric, string, etc.) and how is the data processed before it is sent?

Do you use standard instrument divers or anything homegrown?

[isend73]

Sorry for not providing sufficient info or the vi files in my original post. I finished some critical updates of LabVIEW and the problem disappeared (at least for now). If the problem shows up again, I will find the critical sub-vi's and present them here.

[isend73]

Thank you all for the comments and questions. The problem appeared again. Attached is the zip file of the main vi "ENA-B-sweep-1-pj-sy-final.de-heater-1.vi" and some of its sub-vi's. The instrument is a magnet power supply (Oxford Instruments IPS120), which provides variable current to generate variable DC magnetic field B. The sub-vi "OxITC4 Talk.vi" talks to it. (The main vi also controls another instrument "ENA", but that part does not have any problem.)

Our problem is that, when we make a run with several "jobs" (i.e., loops, each with different "B rate" and "B start/stop" settings), errors occur randomly. The actual "B rate" or "B stop" received by the power supply is either the number we input (which is always in the form of "x.x", including two digits and a decimal point), or 10 times smaller than what we input, or zero.

How can we deal with this problem? If more info is required to solve the problem, please let me know. Thank you very much.

[altenbach]

There are missing subVIs and I cannot tell where these multiple "loops" are.

(On a side node, most people here won't even touch code that contains deeply stacked sequences sprinkled with sequence locals. We don't like headaches!)

[Kyle97330 · Accepted solution]

This seems like more of an instrumentation error than a LabVIEW problem.

First, I would add a log function to log every string send to the instrument at the absolute last point before it's sent (i.e. right before it's wired into a VISA Write).  This can confirm it's not a LabVIEW problem.

If you're using RS-232, swap out the cable you're using or slow down the baud rate to see if that helps at all.

Once you try that, then your options are:

1. Contact the manufacturer for support 

2. Build a workaround

For the workaround, assuming it's OK to momentarily have your power at a low level, just do this:

1. Write set point to instrument

2. Read back set point from instrument

3. Compare set point to read back (remember to NOT just use the "equals" function)

4. If not equal, return to step 1.

[wiebe@CARYA]

And of course: try to make the simplest, functional example that demonstrates this problem. Post that in stead.

Chances are the drill itself revealed the problem... If so, consider posting the solution.

[isend73]

Looks like it's an instrumentation error just as Kyle97330 said. The power supply does not respond at a baud rate lower than the LabVIEW's default value 9600, so I tried the workaround method instead by creating a while loop, which stops only when the difference between the set point (the Write value) and the read-back is smaller than 0.01. Since I built this workaround a few days ago, not a single error has appeared.

P.S.

1. I needed to add a 2-sec wait after Write before Read, or the read-back value could be off.

2. If a significant difference between the Read value and the Write value shows up, the while loop will become an infinite loop between Write and Read unless I include some extra command in the loop before Write, which is a "Remote & Unlocked" command in my case.