Motor/Motion Control Solutions

[Zaacha]

Hello,

I am looking for support on motor control.

I currently use Modbus to control the Kollmorgen drives we have at the Lab, but it is not as responsive as it needs to be.

What are people using to control drives with LabVIEW? Are you not using LabVIEW?

Thanks,

[BertMcMahan]

I like the Galil controllers for bigger stuff, and have had decent luck with Maxon controllers for smaller stuff, too. Anything time-critical will go on the controller itself, as Windows isn't nearly reliable enough for me to trust it for real-time control.

[Kyle97330]

---

@Zaacha wrote:

I currently use Modbus to control the Kollmorgen drives we have at the Lab, but it is not as responsive as it needs to be.

---

How "responsive" is "as it needs to be"?

Is it safe to assume you don't want to completely replace your existing motors and controllers, or do you have the budget for new controllers and motors if needed?

[santo_13]

Checkout GECO Motion - a motion controller specifically designed for LabVIEW - NI Community

[Andrey_Dmitriev]

---

@Zaacha wrote:

What are people using to control drives with LabVIEW? Are you not using LabVIEW?

Thanks,

---

In the past, I used NI Motion and was very happy with it. Nowadays, I use Nanotec drives controlled via RS232(RS485), and they work like a charm.

I have also worked with systems using B&R drives, but in those cases the B&R PLC uses ACOPOS drives, so I simply communicate via OPC UA, which works well too.

In general, almost any drive can be controlled with LabVIEW. The only question is how "direct" the communication is: low-level communication (such as serial or TCP/IP) or higher-level communication through interfaces like OPC or OPC UA. Depends on Drives.

[Bob_Schor]

Combining the previous two suggestions, I believe that when NI dropped NI Motion (which Andrey liked), the "Motion Team" formed TENET Technologies, who makes GECO Motion (which Santhosh recommended).

Bob Schor

[Zaacha]

It seems there is about a one-second delay between the Modbus commands when starting and changing speeds. I would like this to be closer to under half a second at most. I didn't have the issue when using SoftMotion.

And currently, I do not have a budget to replace motors/drives.

[Zaacha]

Thanks, all, for the suggestions! I will need to look into these and see which best fits my needs.

[Kyle97330]

---

@Zaacha wrote:

It seems there is about a one-second delay between the Modbus commands when starting and changing speeds. I would like this to be closer to under half a second at most. I didn't have the issue when using SoftMotion.

And currently, I do not have a budget to replace motors/drives.

---

If you don't have a budget for new hardware then most of the options listed above wouldn't help.  At best you'd need a new controller to work with your existing motors, which you say you don't have.

Modbus should send and resolve quite quickly, in general, as its protocol is very lightweight.  Communications should take just a few milliseconds if you're using TCP Modbus, and maybe slightly longer if you're using Modbus over serial but still sub-50 milliseconds... nowhere near the 1 second delay you're talking about.

It seems far more likely that your LabVIEW code being used to send Modbus commands has unintentional delays in it.  If you can post code samples from your application that has the delay in it, then further advice might be possible (full files, not screenshots).

[rolfk]

We use currently Nanotec controllers with Modbus TCP. They aren't exactly instant but 1s response to start a motion sounds a bit excessive.

That said, for our application speed is not really a big issue as the entire process itself is actually more involved and takes substantial time, so a second more or less is not really something we have been concerned about until now. I'll check today as I'm going to do some tests on that system.