Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

why does vi execute in HIGHLIGHT mode only? Does not RUN from front panel

This is extraordinarily puzzling to me...

 

The attached vi sends a serial command to a motor controller.  Command has the form /1V5500P0R, where the /1 means "motor 1",   5500 is the velocity, and the P0  means "rotate positive direction" and R means RUN (do the command).

 

When I run the VI from the front panel, the motor does not respond.  The correct command string appears in the String indicator box, but, the motor does not turn on.  HOWEVER, when I use either HIGHLIGHT EXECUTION, or I SINGLE STEP through the block diagram, the vi works perfectly.  It issues the correct command the motor runs properly after stepping over VISA WRITE to VISA CLOSE...  The VI accepts any velocity command I want to put in the NUMERIC control on the front panel.

 

I tried putting the code into a WHILE loop to see if that made any difference...and it does not.

 

What is happening?

 

Thanks,

Dave

0 Kudos
Message 1 of 7
(7,317 Views)

 

When a program only works in Highlight Execution, timing is usually the source of the problem. Highlight execution runs your program much slower and probably gives your device enough time to read the commands you are writing to it. I would recommend introducing a delay. The following link contains a Wait function with a VISA wrapper that should fit in well for your code. The amount of time needed to wait can vary anywhere from 50 to 500 ms.

 

https://decibel.ni.com/content/docs/DOC-7008

Regards,

Anjelica W.
National Instruments
Product Marketing Manager
FlexLogger and TestStand
0 Kudos
Message 2 of 7
(7,297 Views)

Hi Angelica,

Thank for you the suggestion about the WAIT function.  Would you suggest putting it between the VISA WRITE and VISA CLOSE?  Also, is there a possibility that a different PC is responding differently.  The last time I used this VI, I was using a slightly older PC, slower, less memory etc.  The new PC controlling this VI is higher performance and is Windows 7 instead of Windows XP.  This VI worked fine on the old PC. I did not see this problem until trying to run it on a new PC.  The new PC has several USB ports.  Can the choice of USB port make any differnece?

Thanks,

Dave

0 Kudos
Message 3 of 7
(7,288 Views)

Hello Angelica,

 

Your suggestion about use of the WAIT VISA function works, however, I am reluctant to use it because I do not want to slow down the application.  The application accepts two inputs and creates the one serial output, and the faster it does this, the better for my application.

 

I had no problem running these VI's on my old PC in Labview 2011.  The new PC requires this WAIT function.  There is software provided by the hardware manufacturer to manually send the SERIAL commands, and it works fine on both PCs.

 

New PC is Intel(R) core(TM) i3-2230 CPU @ 2.2GHz, 3G RAM 64 bit processor and  Labview 2012

Old PC is Intel (R) Pentium (R) M Processor 1.73GHz, .99G RAM, 32 bit processor and Labview 2011

 

Understand that in the attached VI, only a single serial command is being sent, so, is it possible that backlogging or overloading of the device can occur from a single serial command?  This does not happen with the manufacturer's interface.  The attached vi works with the 10ms wait time. This VI is one of a family of VI's that I wrote and operated in Labview 2011 on the old PC, and all of the worked fine without the WAIT function.  Now, none of them will run in either Labview 2011 or Labview 2012 without the WAIT in the VISA as shown in the attached VI.

 

Do you really think that the command is being sent too quickly?  The device communicates over the RS485 bus at 9600 baud, 1 Stop bit, No Parity, No flow control.  How can a single string be sent too quickly?

 

Thank you,

David

0 Kudos
Message 4 of 7
(7,269 Views)

Hi Angelica,

 

One other interesting observation I made with this VI.

 

In this case, I have two serial commands being sent to two different motor controllers.  Even with very high wait times, 5000ms, only motor 1 receives the command in normal mode.  Motor 2 never turns on.  In the block diagram, STring 1 commands motor 1, and STring 2 commands motor 2.

 

However, if I operate in HIGHLIGHT EXECUTION, then, both commands execute and both motors turn on according to the command given very close in time, like within a second of each other!!!! 

 

Thanks,

Dave

 

 

0 Kudos
Message 5 of 7
(7,267 Views)

Hi dav2010,

 

As Anjelica-W said, the Highlight Execution Tool worked because of the timing, this tool usually execute the VI much slower than normal. 

 

You can try to put your code into a stacked sequence with a time delay between frames. Please refer to this link:

 

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/sequence_structures_concepts/

 

Best Regards,

 

Carmen C.

 

0 Kudos
Message 6 of 7
(7,256 Views)

Hi Carmen,

 

I am still confused though.  The HIGHLIGHT EXECUTION actually happens FASTER than the 5000ms wait time!!!  So, this has to be some other issue than pure timing.  In fact, with the 5000ms WAIT, the second part of the code does not execute at all!  I can use the manufacturer's command s/w to send commands manually in less than one second by simply clicking the mouse very fast, and there is no delay.  Please consider other advice for me.  Yes, I am aware of the flat sequence structure, but, every time I talk to a NI support person, they advise against use of the flat sequence structure, and recommend avoiding it.

 

There must be some other mechanism occurring here that is causing the program to fail to execute even at very high WAIT times.  The serial commands are showing up in my front pane indicator, but, they are not getting out to the motor controller.

 

The commands go through a RS232 to 485 Converter which is not a NI part.  I think that NI makes a converter called

NI USB-485, 1-Port RS485/422 Interface for USB, $149.00.  Do you expect that the converter could make any difference?  I don't want to spend $149.00 on an experiment, though.

 

 

Thanks,

David

Message 7 of 7
(7,248 Views)