ELL18K Rotation Stage Bundle - LabView Controller get current position

[LeoTrotzki]

Hello LabView Community,

I just started using LabView in university and am now tasked with building a rotation stage controller, which will later be mounted with a neutral density wheel. 
I got it working pretty well and can move the stage around how I want to, the only problem is, that I can not get it to display its current position in LabView. If I use a "VISA Write" prompt and give the stage the command "0gp" it should give me its current position in hexadecimal, but the return count in the "VISA Write" is only an integer, so I don't know how to continue. 

I attached the VI, so you can take a look at it and maybe even give me general feedback, as I am new to LabView.

Cheers,
Karl

[Bob_Schor]

Welcome to the LabVIEW Forums, Leo.

A nice thing about LabVIEW is it really is an Engineering Workbench (the last two letters of "LabVIEW").  What is probably going on is a VISA communication issue.  I can't look at your code because I'm a long-term LabVIEW User, and our "team" are all using LabVIEW 2019, and so I cannot open your VI and look at your code.  [You can fix this by using the "Save for Previous Version" option and specifying LabVIEW 2019, which should be readable by LabVIEW 2019, 2020, 2021, 2022, and 2023].

Here's how you can "explore the options":

1. Plug in your rotation stage controller.
2. Open MAX (NI's Measurement and Automation Explorer) and select your VISA port in Devices and Interfaces.
3. Open a Test Panel.
4. [I don't have a VISA Device here to test this on, so the following steps are more-or-less from memory, so I'll stop numbering and go into more of a narrative].

The first thing you want to do is to set up the Serial Port parameters for your VISA connection,  These are such things as the Baud Rate (the speed at which the digital pulses conveying the information go up and down, or the speed of data transmission), the Parity, # Bits, and # Stop Bits (often N, 8, 1, No parity, 8 bits, 1 stop bit).  VISA has something called a Termination Character, which you want to set, and make 0x0A = 10.  

Now you want to try sending a command to your device, and seeing if you can read a response.  Look in the manual -- there is probably an "Initialization" command, which often gets a response back.  This may be on another tab in the Tester.  Once you send the command, you need to read the response.  How much should you read?  Well, you don't know, because you (probably) can't predict the future and know how many characters the response should be!  But VISA knows, and will send you a "Bytes at Port" (how many bytes is it ready to send to you).  You should not use Bytes at Port, especially if you turned on the Termination Character (see end of previous paragraph).  Tell VISA to read 1000 bytes.  It will probably send back 5-20 bytes, the last one being a "Line Feed" (0x0A, 10 decimal), which makes VISA stop reading and return the just-read bytes to you.

Once you get this to work, you can try more complex commands.

Now, when you write your code, you go through the same steps.  You do a VISA Configure Serial Port (most of the inputs to this are probably correct, except possibly the Baud Rate, whose default of 9600 is probably much too low).  Follow this with a VISA Write, then a VISA Read, with a byte count of 1000, and look at the (much shorter) string that is returned.

Give it a try, let us know if/how it worked.  And (re-)attach your code saved for a "previous version", please.

Bob Schor

[LeoTrotzki]

Hello Bob,

thanks for the reply. I am already able to move to motor and send it the commands I want, I also know which commands to send and what I would receive, because I used software by ThorLabs, where I get those informations. 

Problem is, that I know I would receive a hexadecimal (so a string) output, and all the VISA terminals I found so far, only either allow me to send in a string and receive an integer, or vice versa, but I would need something to receive and output a string. 

When I tried using "VISA Write" it would just give me a random integer, which sadly was of no help. 

I converted the VI to the 2019 version though, so maybe that can clear things up.

Cheers,
Karl

[LeoTrotzki]

PS: Still can not quite to get it to work, but could I just have a "VISA Read" after a "VISA Write" to make it work?

[Bob_Schor · Accepted solution]

---

@LeoTrotzki wrote:

PS: Still can not quite to get it to work, but could I just have a "VISA Read" after a "VISA Write" to make it work?

---

It depends.  When you do a VISA Write, you are often "sending a command".  Look in the manual for your Controller -- when you send that command (like "Where Am I?"), does it send an answer (like "X = 20 cm")?  If so, it has responded by sending you something to read, so in this case, yes, it is waiting for you to issue a VISA Read.  [If you read my previous long response, you'll know to ask for a "big read", like 1000 characters ...].

Bob Schor

[LeoTrotzki]

Thanks a lot for the help! 

I can now get readings that are the same as the software provided by ThorLabs, I have to use some workarounds though. LabVIEW always skips the first 2 steps and also every other step, probably because I have my while loop weird. I just add the degrees per step times 2 to the current position and multiply my reading by 2 afterwards. I guess it could become a problem later, but for now this works. 

If you have any idea for a smarter workaround, I would greatly appreciate!

Cheers, 
Karl

[LeoTrotzki]

For anyone wondering how I got it working now, when you have the same problem:

I opened a new "VISA Serial" and made a separate while loop for it, because the other loop was bound to a timer, since I wanted the motor to move in certain time steps.

In the new while loop I put in a "VISA Write" followed by a "VISA Read" and gave it the correct command being "0gp". In the software provided by ThorLabs I could figure out how many bytes I would need in general and how many I would have to cut off. 

So now I am getting a correct reading without any kind of workaround.

Cheers, 
Karl

[Bob_Schor]

Your attached "Wheel Controller.vi" (thanks!) is written with LabVIEW 2023.  I routinely use LabVIEW 2019, so I cannot open your VI and make more specific suggestions because I'm only "guessing" at your code.

Could you open your own VI, then do a "Save for Previous Version" (on the File menu) and specify LabVIEW 2019?  [Perhaps call it "Wheel Controller 2019.vi"].  I'm sure you'll hear from me, and from other long-time LabVIEW users (we generally do not install a new version of LabVIEW every year because of the compatibility issues with older LabVIEW installation).

Bob Schor

[LeoTrotzki]

I did that for that file, don't know why that is not working.

I did the same process again and this is the file, maybe it works now?

[Bob_Schor]

Oops, my bad -- I must have opened the original 2023 version by mistake.

To make up for your extra effort (and my carelessness), here are some suggestions for "improving your code" and "getting better at LabVIEW".

• Square Boolean Buttons (and specifically the Stop Button), by design, have the Mechanical Action "Latch when Released".  You should (until you become a Real Expert) not change this, but instead "take advantage of this".  These buttons are designed to be "triggers", read once and then "automagically" reset to their default (usually "False") state.  When they are "light gray with easily-read writing on them", they are in their default, "False", state, waiting for you to push them.  You should wire them directly to where they will be used -- in the case of "Stop", this is usually to the Stop Control of a While loop.  So you push it, nothing happens (except the Button turns dark gray), then you release it, it automagically turns light gray again, and your While Loop stop.
• Square Buttons (with the default "Latch" property) are also often used in Event Structures, which are often used to monitor changes on the Front Panel of the Top-Level VI.  However, their Latch property means (among other things) you cannot "fool LabVIEW" into thinking you've "pushed the button" by using the Value-signaling property that works for other Controls.  [If you don't know what this means, you'll learn it soon].
• You (probably) don't need the upper Frame Sequence structure -- you are only using it to insert two 1-second delays in your VISA routine (which you probably don't need -- see the next point).  If you do want to insert a delay, I recommend using the "Stall" VIM located on the Timing Palette.  You can drop this on any Wire (the Error Line is my usual choice) and wire the number of milliseconds to wait.  Keeps the code much neater and more compact.
• Do your two VISA commands return values?  Do you need a VISA Read after each VISA Write?  Whether you do or not, you probably do not need a delay (if the remote device can receive the "Set Home Position" command without returning an acknowledgement, it should be able to immediately accept a "Move servo to Home Position" command.
• A way to "neaten" your code would be to write a subVI called "Set Home" that has the default 4-2-2-4 Connector Pane, an Icon that says "Set Home Pos", VISA In and VISA out at the top corners, and Home Position (as an I32 or Dbl, depending on what your device wants), and Error In and Error Out at the bottom corners.  Inside, you "build the command" (it looks like VISA wants a string starting with "0so" and followed by an 8-digit numeric, easily created with a Format Into String that sits on the Error Line, takes the header "0so" as the Initial String, your Home Position in the lower left input, and a Format String (on top) of %08d, which means "8-character integer with leading 0's".
• To create a simple VI Icon, right-click the LabVIEW Default Icon (top-right corner), and choose "Edit Icon".  You'll want to see the Layer's tab, so if it isn't visible, click "Layers" and turn it on.  Click the Layers tab, and in the User Layers on the left, click the little VI Icon, and then the "X" (delete) to the right of the "viewing eye".  Look on the right, where the Default Icon used to be -- this is where you'll create your new (very simple) Icon.  See the little Blue Box?  That makes a "filled Box" with the Edge and Interior colors shown just below (here Black edge and White interior).  Click the Blue box, move your cursor to the upper left corner of the drawing space, click and hold while you drag the box down to the lower right corner.  You now have a "Blank Icon".  Now click the Icon Text tab.  In a few lines (short words), identify this VI (I used "Define", "Home", "Pos").  Oh, on this page, I've set the Alignment as "center", the (unlabeled) size as 10, and Capitalize Text as False.  Now if you put this sub-VI down on your Block Diagram, it will have a "crude but effective" identifier that tells you and other users what this is supposed to do.  Click "OK to exit the Editor, saving your no-longer-default-looking sub-VI-with-icon.
• You can do the same, creating a sub-VI called "Move to Home Pos" that "sits" on the Error Line.
• Let's think about the "Move to certain position" button.  It probably does want to be initially False (but maybe not?), but how is it used?  The next While Loop waits for it to become True, and when that happens, it both "does a move" and turns itself off.  Remember my discussing Square Booleans that have the "Latch until Released" property?  If you put the "OK" button on your Front Panel, renamed it to "Move", and changed its Appearance property to show "Move" instead of OK, you wouldn't have to set it initially False, nor False inside the While Loop.
• At one of the first NI Week conferences I attended, they showed this "new" property of the Error Line -- you could wire it into a Boolean, and it would look at the Error condition.  What do you want to have happen if your While Loop has an Error?  Throw Error, Error, Error, ... as fast as the While Loop can run until you push Stop?  Or to immediately stop?  You can wire both the Error Line and the Stop Button to a Boolean "Or" function and wire the output to the Stop Control -- "Stop While Loop on Error or Stop Button".

Bob Schor