VXMDriveLV8.vi documentation?

[thej178]

Hello, I am trying update an existing code that was provided to me. We are using a VXMDriveLV8.vi which allows us to communicate to our VXM stepper motor controller using LabView (2013). The inputs/outputs context help is helpful and almost self explanatory, but I need more information and can't find documentation for this vi anywhere. Specifically, I want to understand reasoning behind setting certain timeout values and need to see the documentation to know what certain values mean. Does a 0 wired to a time out imply wait indefinitely or to not wait at all?  What are default values? Items like these. Does anyone have any idea where to find more documentation for this vi?

Thank you

[GerdW]

Hi thej,

We are using a VXMDriveLV8.vi  … where to find more documentation for this vi?

I would ask the one who created that VI. Did you?

[thej178]

The person who originally created this is no longer available. When I open the driver VI I can't exactly tell if this was created by NI or by a user. It is a little "freehand" so maybe it is user created. Inside the VI, DLL is used to call up various functions from somewhere and that's basically as much low-level as I can get within LabVIEW. I was able to track the location of the VI and there are some instructions and documentation. It still looks like it came from some other, more official source though. The documentation there seems to reflect more of a Velmex instruction set though. I'll look through it more and update you. Thank you for the feedback

[GerdW]

Hi thej,

The documentation there seems to reflect more of a Velmex instruction set though.

So you got a hint: a company or product named "Velmex".

You should start to look for that and to find support from that manufacturer…

General hint: drivers for 3rd party products mostly never will be created by NI. That 3rd party is responsible for its drivers.

[thej178]

Hi, I ended up finding some documentation! But it took some searching. Though it appeared as a packaged product, it turned out to be DLLs calls written by someone internally. I contacted Velmex as well and they weren't aware of this themselves. All resolved now!