From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview velmex

Hello all,

I am fairly new to the forum, but I have been checking for postings about controlling a stepper motor using the Velmex VXM stepper motor control.

 

There seem to be some complaints about various things such as the driver freezing, or that there are too many inputs on one wrapper VI

 

So please be kind and not beat me too badly when I say this......

I am the poor putz that wrote the driver and it has been in use for many many years, and I admit that I know next to nothing about Labview programming. (To me its like programming with pictures) but it may be time to update code and create a newer driver and its wrapper functions.

 

I would like some input from those of you out there that have used my driver before and what you liked or disliked about previous versions.

In my past at one point I had a separate VI for each function that was in the driver, then I switched to one VI with many inputs for all the functions (which was based on people not being able to find the appropriate VI for what function they wanted to call), but now I read complaints of not being to find what they want with 1 VI with many inputs

 

So I ask, which is the proper way to let users easily call each funtion in the new driver?

 

My other sore point is where I read that documentation was "Lacking".

I can not figure how it was "Lacking" when there was a folder clearly named "HOW TO USE VXM DRIVER" in each of the examples?

 

I would like to make a better attempt at what the community as a whole is used to, however before someone says to just write the driver in Labview, you must remember I am just one programmer and the users are MANY and amongst many different languages and versions, so it is very unfeasible to write a new driver in a language I am not used to and is not exchangable in all the languages that I have run into over the past 15years.

 

"Let the Beatings.......BEGINNNNNN" Smiley Very Happy

Message 1 of 52
(5,573 Views)

You talk about wrappers, so I am assuming the wrapper is talking to a dll.

 

I'm assuming you have the source code to the dll, so...

 

Open up LabVIEW.

Navigate to Tools --> Import --> Shared Library (.dll)...

 

Follow the wizard.  You'll end up with a VI for each function.  That would be your starting place.  If you have questions about the wizard, ask away.  Or just build them and upload one or two here so we can look at them...

 

Good luck - and it is a noble quest that you are on.

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 52
(5,530 Views)

We had done this so many times for customers in R&D environments that we wrapped it up into a product with examples and a turnkey XY application:

 

http://interfaceinnovations.org/motionproducts.html

 

Happy to help or answer questions.

Colin

PhD ChemE, CLD, Alliance Partner : www.interfaceinnovations.org
0 Kudos
Message 3 of 52
(5,347 Views)

While I've never used your drivers / hardware, I applaud you for coming here to seek suggestions for improvement to your LabVIEW drivers.

 

All too often as a developer I download a 3rd party driver only to find that there are fundamental problems with it or it goes against NI's guidelines / common practices for driver development. We usually end up having to modify / rewrite some of these drivers for the functionality we need which means we're more likely to miss out on issues that are resolved in the supplier's driver.

 

This includes major things like the library "just not working" and situations where the library would completely block execution (while loops where the exit condition is never met) and minor things like non-standard connector panes.

 

Other companies, including some large internationals, should follow your example!

 

I understand that it's all too common for a company that a customer comes to you and says "do you have a LabVIEW driver for X?" Smiley Very Happy

 

As for what you should do...take a look at some of NIs own drivers/APIs e.g. DAQmx for inspiration. Generally VIs for Configure, Init, Action VIs and Close is a good guideline to follow. Make sure that you've documented the VIs (in VI properties) so you can see the description of what the VI does in the context help.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 4 of 52
(5,316 Views)

Hi,

 

I am a first time user of LabView and VXM.

I wanted to know if there is a VXM dirver existing for MacBook.

 

Also wanted to know how to import this driver in the LabView installed on a Mac. I appreciate any help in this.

 

Thanks

Mridu 

 

 

0 Kudos
Message 5 of 52
(5,142 Views)

The Velmex driver is quite old and appears to call a .dll, making it Windows-only.

 

When you look at the VI, it is very poorly written and not documented well. 

 

Several years ago I wrote a driver simply using the serial port commands. It worked quite well with the Mac.  I no longer have access to that code, but I recall that it was not difficult to put together something by following the commands in the manual.

 

Lynn

0 Kudos
Message 6 of 52
(5,133 Views)

Hi Lynn,

 

Thank you for your help. Can you please tell me what manual I can use, as I am very new to both LabView and VXM? I would really appreciate any pointers in making this driver.

 

Thanks again,

Mridu

0 Kudos
Message 7 of 52
(5,094 Views)

Look at their web site. Find the manual for the controller you are using. Look at it to see if it has the ASCII commands to send to the controller via the serial port. I do not have time right now to go through the manuals to find it, but I recall that the command set was documented reasonably well. In a few cases you may need to send  a command to the controller to see exactly what it does. Writing some simple test VIs is almost always a good idea when developing a driver for a new instrument.

 

Also, look at the requirements for your project. You may not need to implement every command in the manual. You should do the initialiazation, shut down, and error handling parts regardless.  I do not recall whether that controller has acceleration limiting but if you do not need that and the default values are fine, do not spend time implementing commands to control those limits.

 

Lynn

0 Kudos
Message 8 of 52
(5,057 Views)

"When you look at the VI, it is very poorly written and not documented well. "

 

Poorly Written???? (Maybe if you "Program using pictures" instead of using Real Code)

 

Not documented well?????? (Maybe that is because someone did not read the documentation included with the driver, that is so dubiously hidden in the Examples\HOW TO USE VXM DRIVER folder ?????)

 

Either point is mute, because the OS in question is for a Apple and not a Windows based machine

 

The part about it being old does not matter because the actual commands sent to the serial port are still the same.

 

I would be open to ideas for a future version that is not limited to Labviews constraints of (what I think is 16 I/O per VI) without having a folder just chock full of VI's to call each function separately (which is why I went to 1 VI because of complaints of why so many VI's in previous versions????)

 

0 Kudos
Message 9 of 52
(5,031 Views)

Poorly Written???? (Maybe if you "Program using pictures" instead of using Real Code)

 

Block diagram > two screens tall.  Front panel > two screens tall.  Sequence structures all over the place.  Local Variables. Excessive bends in wires. Right to left wiring. No error handling or error out indicators.

 

All of those are considered indications of poor LabVIEW coding.

 

Not documented well?????? (Maybe that is because someone did not read the documentation included with the driver, that is so dubiously hidden in the Examples\HOW TO USE VXM DRIVER folder ?????)

 

No documentation exists in the VI except for a few free labels, most of which duplicate the control names. At the very least a note on the Block diagram or in the Context help could point to the documentation in the Examples folder

 

Either point is mute, because the OS in question is for a Apple and not a Windows based machine

 

My point is that I have written a driver which uses the ASCII command set and works fine on the Macintosh OS. Although I did not test it, it likley would have worked without modification on Windows or Linux.

 

The part about it being old does not matter because the actual commands sent to the serial port are still the same.

 

This may be true of the results. Some of the style guides have evolved over the years so that what was considered "good" LabVIEW code then may not be as acceptable now. 

 

I will send you a PM tonight or tomorrow to address your last issue.

 

Lynn

0 Kudos
Message 10 of 52
(5,010 Views)