Active-X versus NI-cDAQ (protocol/ timing issue?)

[Carsten_Schmidt]

Hi, I'm having a hard time with Thorlabs Stepper Motor controller (BSC202), which is controlled via an Active-X environment.Since it is only one piece of hardware in a larger setup intended to work automatically, power to this and other devices is supposed to be controlled via NI-cDAQ (9174-9481) relays. However, if the relay was switched off before starting the .vi, an error  message will pop up informing me of "+5V digital under voltage" inside the controller somewhere. If I close the message, everything will work fine, despite this notification - not a surprise, as error state is false (investigated with sondes). If the controller was powered on before executing the .vi, no message will appear and everything works fine.

I could actually live with the notification, if it wasn't requiring manual interaction. I tried several things so far:

1. Both devices (cDAQ, BSC202) are connected via USB, so I changed cables, ports and added a powered USB-Hub. Especially, the latter had helped with similar issues in the past, but not now.

2. I tried to ignore the pop-up by disabling automatic error handling

    a) in "Vi-Execution..."-properties

    b) and "tools-options-block diagram..."

It will pop up anyway and I don't know why (the official error output of the wire is false!).

3. I tried different waiting intervals to establish USB-communication (>1Min)

Worse: the entire setup had been working correctly for several months (unfortunately developed by someone else). So my first guess was: the hardware was actually damaged during a transport. But why would it be working, when switched on before program start, if actually damaged?

Is there a better way to control the hardware? I'm afraid it's an Active-X issue, which I don't get, because I'm not really familiar with Active-X.

Are there more options to ignore pop ups requesting manual interaction, which I don't know and couldn't find in other posts?

Is it a real hardware error?

System is Win7, LabVIEW 2012, screenshots of minimum code example and pop-up dialog box attached attached.

thanks,

Carsten

[Bob_Schor]

Carsten,

     It is really difficult to work with pictures of code, but easy to work with VIs that you attach to your Post (see "Attachment" button on the left just before the Reading/Replying window).  For one thing, it lets us move around your code easily, click on functions we might not recognize, and actually try to run your code (if appropriate).  It really helps us to help you.

Bob Schor

[Carsten_Schmidt]

Hi Bob,

no problem, I just thought, it wouldn't help much without the other drivers and hardware being attached. Also there is an update to the problem: The notification popup will occur, whenever the hardware is first adressed after being switched on. Actually, it doesn't matter, if it was switched on before starting the .vi or not  (obviously I was working sloppily yesterday). I'll contact Thorlabs staff, they should know, what this notification is supposed to tell me (maybe it's really a hardware issue).

But do you know how to suppress this popup? I tried the usual ways (see original post), but it will pop up anyway. I have a very brute force workaround (which I'm not proud of), but it makes the system work. I'm open for better suggestions.

I call two batch files at the same time:

Workaround_part1.bat

- starts LabVIEW – schm_test3.vi (popup will occur waiting for manual interaction)

- killed by „workaround_part2.bat“

Workaround_part2.bat

-started at the same time as „workaround_part1.bat“

-kills one or more LabVIEW instances (brute force) 2 minutes after being started

-Starts LabVIEW – schm_test4.vi afterwards

batch file source code (.vi property "start execution when opened"):

Workaround_part1.bat:

@ECHO OFF

"C:\Users\GRIPS 14\Desktop\schm_test3.vi"

REM EXIT

Workaround_part2.bat:

@ECHO OFF

ECHO call wait.exe in system32 directory, wait 2 minutes, then kill LabVIEW

WAIT 120
TASKKILL /F /IM LabView.exe /T
TASKKILL /F /IM LabView~1.exe /T
WAIT 10
ECHO restart LabVIEW with actual .vi
"C:\Users\GRIPS 14\Desktop\schm_test4.vi"

REM EXIT

[Bob_Schor · Accepted solution]

This is crying for a State Machine-like model, possibly with optional Data (a Queued Message Handler?).  You have two MG17 Motors, a Digital Output thing that you don't seem to be using here, and then a sequence of actions.

Also, sometimes it makes sense when Development is giving weird results/errors to simplify things, so I'm going to discuss a single-motor system (if it works for one, you can add on the second or simply run two in parallel).

Consider Test 4.  Here are the Actions/States:

   Initialize the DIO (I guess you are using this to turn on two Power Supplies?).

   Wait (data = 15000, # msec)

   Start motor (Serial # and Control seems unique to this case, can be define here and carried in Shift Registers)

   Wait (data = 10000)

   Send motor Get Position command (data = cluster of Command and Channel ID)

   Send motor an Absolute Rotation Move command (data = cluster, not sure why some are doubled, also puzzled by whether the Node elements are Inputs or Outputs, looks like both?).

   Wait (data = 2000)

   Send Motor another Absolute Rotation Move (data = cluster)

   Send Motor Stop Command.

   End the Loop

You implement this as a While (or For) Loop containing a Case Statement where the Cases are the Actions or States (it's cleaner if these are Enums).  The Error Line is put on a Shift Register, the Motor Reference is on a Shift Register that is initialized when the Start Motor command is given.  Look at how the Queued Message Handler bundles a Message (here called an Action or State) with optional Data by making a Cluster of State + (variant) Data.  You can "drive" this loop by creating an Array of Commands + Data for the various States described above and using an indexing Tunnel to peel them off, one at a time, unbundle the State and wire it to the Case Selector.  If the Case is, say, a Wait that requires a Delay parameter, simply take the Variant part of the Command+Data and do a Data to Variant using a U32 as the type, which you wire to a Wait (ms) function inside the State (that's an easy State to code).

[No, I'm not going to mention Objects here ...].

When the Error Line comes out of the Case Statement and is going to the shift register to loop back to the beginning, test it, and if there's an Error, stop the loop and report it.  Otherwise, your last State should stop the loop.

You'll end up with much more compact code, one that puts you "in control" of what is happening by simply changing the "orders" contained in the array driving this engine.  You can easily extend this by coming up with other means to get commands in rather than reeling them off from a (static) array.

In the Getting Started with LabVIEW initial screen, there are some sample Projects that you can build which I believe include both a Simple State Machine and a Queued Message Handler, from which I borrowed some of these concepts.  You'll understand it better if you "do it yourself".

Bob "Been there, done that" Schor

[Carsten_Schmidt]

Thanks, a lot for your efforts Bob. I'll consider (parts of 😉 ) your suggestions.

Meanwhile I got feeback from Thorlabs support. Actually, one of the several hundreds of available methods is called "Enable Dialogue", which accepts a false input, so the pop-up message can be suppressed. Unfortunately, the message is supposed to indicate an imminent serious failure of the hardware, likely related to the recent transport.

again: thanks a lot, I'll return to refreshing my LabVIEW skills, which lay dormant for a few years,

Carsten