SMC100 Controller Real Time Position Problem

[simply_me]

Hello,

Background: I'm working with SMC100 controller in the lab to move a stage along an axis, and the movement range is in the order of 1-1000 micrometers.

Goal: The general arching goal is to create a vi that will automatically detect the region of interest (move between two peaks back and forth). I haven't started to program the peak detection algorithm, and it's not the issue yet ;-). 

Current problem: Labview comes with SMC100 controller drivers in its example library, but the vi that suppose to report current position doesn't report it accurately. By not accurately I mean that it seems that there is a delay in position reporting which is crucial for the peak range algorithm to work. The vi in the example is straight forward (read/write), so I'm puzzled why the delay. 

I would appreciate any suggestions on how to modify/change it.

I've attached the vi that I've made using the vi's given by NI, it essentially moves the stage back and forth between two ranges (user defined).

Thank you,

A

[Matt_McLaughlin]

Hi simply_me,

Did you obtain the SMC100 controller drivers from the controller manufacturer or distrubutor? Checking our Instrument Driver Network the only SMC drivers was only able to find are third party developed drivers for a signal generator. Is there something I am missing there?

If you did in fact obtain the drivers from the controller manufacturer, it may be most helpful for you to contact them directly with questions on the drivers.

[simply_me]

Hi Matt,

Thanks for the advice, I've contacted Newport rep today and informed him of the issue, but he hasn't got back to me yet.

What makes you think it's a driver issue vs. a vi issue? I think the amount of data that the driver and motor pass is pretty low (compared to CCD with a normal ROI); just curious.

The vi themselves are provided by NI (in lV examples).

In your link, I've only found drivers for SMC 100A which is a function/signal generator and not the discussed controller by Newport (SMC100CC connected to MAF-CC mini linear stage). Can you provide me with a link to the third party you mentioned above?

Thank you for your help,

A

[Matt_McLaughlin]

Hi,

I don't believe that these VIs are a part of any NI created toolkit or driver. Did you download them from Newport here? When I mentioned a third party instrument driver, I'm referring to a set of VIs created by the third party to ease communication with their device in LabVIEW. I'm sorry for the confusion on that. These instrument driver packages will often contain example programs as well.

If I am mistaken on this, please point me to the location where you found these examples. Otherwise, if you know where I can obtain these instrument drivers, I can install them and take a closer look.

[simply_me]

Hi Matt,

You are correct, it's my mistake. I thought they were because they were in NI folder, and I wasn't the one who installed it initially. Apparently, the latest version of the drivers is installed (version 2.0.2) on the machine. I checked it with the link that you've provided. Their provided examples, also, do not provide real time update to the position (i.e. It doesn't update every second or less) which is very strange.

I'd appreciate it if you can take a look at the drivers.

Thank you,

A

[Matt_McLaughlin]

Hi.

Is the problem that there is a delay in how quickly the current position is reported back or are the current postion values incorrect, as if the 'tell current position' subVI is reporting a previous value?

As you said, these VIs are based on simple VISA read/write commands to the device, so it is unlikely that there is a problem in that regard. If you could include more detail on how the position is being reported and why you suspect that it is delayed, it would be helpful. Would included and 'tell current postion' before the loop to get an initial position reading be helpful? From what I see, the VI simply tells the instrument to move to a position, wait until that position is reached, and then read back that position. If there is a problem it is likely based on the instrument incorrectly interpreting the VISA commands or the encoder reading being incorrect. Can you manually move the system and monitor the encoder readings from the 'tell current postion' VI?

[simply_me]

Hi Matt,

Thank you for your assistance, I appreciate it.

After a more careful examination, I've placed an iteration counter and elapsed time indicators in the vi (as you can see in the attached files), and I found out that given the parameters: velocity of 1 micro meter per second and a range of +/- 5 micro meters, the loop took ~45 seconds for four iterations. About 11 seconds per iteration. This makes sense as far as distance/velocity yields the total time, but I'm not clear as why it only does 4 iterations.

I would like to see the current position indicator updated several times in a second.Is there a way to get an updated position (similar to a waveform graph data, , instantaneous update, if that makes sense) ?

Sincerely,

A 

[Matt_McLaughlin]

Hi,

So, the answers to this question will depend on the functionality of the LabVIEW driver that we are working with and how it sends commands over VISA. It looks like the "Move relative" VI only sends one command to the controller, so you should be able to poll the device with the "tell current position" VI while this motion is executed without causing a resource conflict. The question would seem to be whether you are able to run the "tell current position" consistantly without interfering with the "wait for stop_1axis" VI. Unfortunately, the version of the driver that I installed does not have this function, so I can not look into it in detail, but it may be worth a test to see if you can call the "tell current postion" in parallel with the wait function.

Does the "wait for stop_1axis" just make sure that the program doesn't move on to other movements before the first has finished? If this is the case, you could perhaps call the "tell current postion" in a loop checking against the previous readings. If the previous position reading is identical to the current, you could stop the while loop and move on to the next command. Does that sound like a possibility?