Sample LabView VI or Driver package for communicating with NexGen controllers

Hello, folks. I am searching for a sample LabView VI or a driver package for communicating with NexGen controllers; I will be using a SDC1130.

I have searched the forum on this subject and found 4-5 year old posts, but nothing recent. Please let me know if you are willing to share your code.

Cheers & thanks in advance, -Alex (Paso Robles, CA)

I recently had the same problem and found it all to be quite confusing. Hopefully this response will help you.

To communicate via the USB or serial connection with the controller via LabView, you can start with the example that comes with LabView called \"Basic Serial Read and Write\". You will have to add in the configuration settings (like stop bits, baud rate, etc) for your particular controller. I found these values in the datasheet for my device. If I recall, it also took a little bit of messing around with the settings in the computer for that serial port, but I don\'t fully remember what I did or whether it ended up being necessary. I think that may have been to get the termination character to work correctly.

See \"Section 16: Commands Reference\" of the Roboteq Advanced Digital Motor Controllers user manual to learn what commands to send and what the responses mean.

If you want to have an automated script, then you write it in the MicroBasic language via the Roborun software and load it onto the controller via Roborun. Then you can use LabView to tell the controller when to run your script (with the !r) command.

I have created a VI that should work for your purposes. It is still a work in progress, but should get you started. It only has a few of the commands built into it that I need, but it should be simple for you to add more.

The VI uses a sub-vi that I modified from zone.ni.com/devzone/cda/epd/p/id/2757 to determine if a Roboteq device is attached to the computer. I will try to upload that in another post.



Elizabeth

Hi, Elizabeth, and thank you for the reply. I\'ve downloaded both the \"Basic Serial Read and Write\" and \"find_visa_com_resources\" VIs and will begin looking through them. I would appreciate it if you can post your modified version, even if a work in progress.

Yes. I tried to attach it originally but then found out this forum only allows pdf files to be posted. Ran out of time then to deal with printing it as a pdf. Will not have that computer with me til Monday but I will post a pdf of the file then. I can email you the VIs Monday if you provide your email address. (Looks like you should be able to go back and edit the post so that your email address is not permanently on this forum).

Elizabeth, please email the VIs to my work address at This email address is being protected from spambots. You need JavaScript enabled to view it.. Thank you in advance, -Alex

Here is a simple VI to send a serial command to the SCD2130 and another VI to determine the port that the motor controller is connected to.

Hi EveryOne ,

I have found in the Roboteq forum that you have been working on controlling an agv with roboteq controller using Labview.
I had the same idea but a have so many questions regarding this :
1/ Can i use a PLC with the roboteq magnetic sensor and motor controller.
I'm plannig to make the agv stop at certain point that i will have to decide from a hmi(labview VI).
2/ Is this possible to do ? If yes ?Any suggestions how ?

Sorry for bothering you , but it will be very helpfull.

A couple years back I put together a VI that would send individual commands from a pull-down menu, send directly typed commands, as well as read a script for automated testing:

Time Action
Time Action
Time Action

Of course it was datalogging feedback while doing this.

I had to leave it behind at the company I was working with... but now find myself needing to build something similar... Hopefully I will get permission to post it for use. Simple code but a few tricks around finding COM ports automatically, parsing the input, automatically parsing input into proper form, and framework for accuracy and precision testing.

RoboteQ is a mixed bag... They, like many, focused first on getting the hardware to market and then chased advanced functionality in firmware. We ran into quite a few functions which were not working as advertised... but to RoboteQ's credit... they took feedback and released firmware updates to meet requirements.

There is a lot of undocumented behavior to tip-toe around. I can say this... if your system is not working as expected... it is probably just due to minutia. The controllers for the most part work as advertised and they are highly complex in terms of options.

I use the FBL2360 and am looking for a smaller lighter version... maybe a FBL2330... as our average power requirements are quite low.

-methods

Ok - I wrote the code again. A little different this time:

* Searches available COM ports and auto selects RoboteQ by sending a QRY
* Allows manual entry of commands (as Roborun does)
* Spills communications for plain view (like Roborun)
* Accepts a basic CSV in the format of Command, Delay - like this

!G 2 100, 100
!G 2 350, 500
!G 2 0, 0
!G 1, 200, 300

Where the above would set motor 2 to 10% then wait 100ms, then set motor 2 to 35% for 500ms, then set motor 2 to 0 with no delay, then set motor 1 to 20% for 300ms

Its very simple to parse so any format could work... that's just what I happened to need.
Tomorrow morning I am going to: (on my own time, as I a have already burned my "do not exceed" billable hours... but I enjoy this...)

* Enter ? values into the script
* Parse the data coming back for the Hall signal states
* Display the hall sequence for correct order verification (Something Roborun does poorly)
* Possibly graph the hall signals vs RPM and Voltage (or something useful - the only difficult part is the general expressions that will scale for any input)

I am running an outrunner with built in toggling hall sensors as well as a Quad encoder.
Quad encoders are not free, and the motor has a high pole count, so in an effort to cut bomb cost I may:

* Run a script that exercises the motor bi-directionally while logging Hall Count and Encoder Count then calculate % difference
* Try to get the hall sensors to shutter or otherwise get glitchy

I suspect that we can eliminate the ultra-high resolution of the quad encoder. Everyone loves them... but not everyone has had super high pole count motors to work with along with a "smart" controller that does not just count blips, but rather counts halls including direction to filter noise.

Not sure how much hysteresis there is on this hall set... not all are created equal and in my Ebike experience I have seen some that can rapid-fire if you get the magnet in just the right spot. I believe some use time hysteresis and others use amplitude - not an expert in them.

So yea... once that is done I will post screen shots and perhaps a link to a video proving operation. Normally I would just give it away in the Open Source spirit but my accountant politely reminded me that we are 3 months behind on rent and I am not allowed to do any more non-billable work...

So I am not trying to drum up work - but if someone wants LabView to run with RoboteQ PayPal me a hundred bucks or something and I will give you what I have.

As for CANopen - if you are an expert in this field (I understand it low level and have implemented similar CAN protocols back in 08' but I am not an expert nor am I sitting on any good code sets or hardware) I would be interested in trading work with you. I have need for a good low cost CANopen implementation to get back and forth across protocol's in a BMS we are working on... just food for thought.

Anyway - back to RoboteQ...

I love LabView and try to promote its use... so if you are just stuck on something and need a quick pointer or simple VI... I will help you out if you have time. My Phone number and Email are here: www.schindlerengineering.com/contact/

(I do pro bono work to a fault... and will help you for free if its quick or interesting... but I am also looking for FTE and contract work at the moment)

-methods

Code Example: How to use Regular Expressions to parse a datalog for unique hall states to ensure the wiring is correct:

I send this script:

!G 10 // Turn both motors forward at 1%
# C // Clear the buffer of commands
?HS // Command that Hall State for both motors be returned (form: HS=n:n, valid states 1-6, 0=fail, 7=open)
?C // Unrelated Encoder Count on both motors (just to put a mess in the datalog coming back to force us to parse)
# 1 // Command that the command buffer be sent out on a 1mS interval

From that... we get an output that looks like this: (note the motors run for 1 second until WDT kills them)

C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023
HS=6:2
C=19950:3023

It is important to realize that we are respecting Nyquist limit... and we are oversampling... so we EXPECT to get multiple hall states back that are identical... so for this to be a useful exercise we have to filter matching results and log only unique instances.

Example of filtered result, where duplicates are removed

HS=6:2
HS=6:6
HS=4:6
HS=5:6
HS=5:4
HS=1:4
HS=1:5
HS=3:5
HS=3:1
HS=2:1

Where we are interested in the sequence that looks like this for a single motor:

110001
011100
000111

132645

For a single channel of course...

Here is a code snippet that uses a regular expression to pull only the Hall State from the data log then removes duplicates to allow a clear sequence to be identified.
This code is not correct... in that it triggers "as different" when either motor 1 or motor 2 changes.

To correct this code another regular expression is used to parse out the HS= #1 : #2
Where we are left with hall states for M1 and M2
And then we can collect the first 6 transitions starting with 1
Sequencing through 132645

And thats what I am going to do next, with an LED light on the screen, that indicates positive if the hall sequence is hooked up correctly.



SO.... thats the best way I can tip you off to how LabView can work very well with RoboteQ without spoon feeding you the end result.
I will post a few more examples as my program matures.

-methods