SimplemotionV2 - Ethernet driver

#1

Is it it possible t run SimplemotionV2 straight off the Ethernet port? Is there any plan to support this instead of using the USB interface?

I know there is an ethercat product in the making, but wouldnt Simplemotion be able to be bridged directly , if a translation driver was created that could talk to the interface right over the ethernet port?

Or even better question - would it even be possible at all?!
I’m a linuxcnc user and have tired of running my argon drivers as analog 10V signaled drives.

#2

Hi

Direct ethernet connection would need specific electronic to handle that communications, and this would require drivers to the PC/PLC end. Also, this is very specific way to use simplemotion and the customer base would be extremely small. So there would have to be a lot of changes without practically any benefit.

It’s possible use simplemotion with the SMV2USB adapter. You’ll just have to change Linux USB parameters to enable 1 kHz update frequency.

https://granitedevices.com/wiki/FTDI_Linux_USB_latency

Kind regards,
Esa

#3

Yeah i guess that makes sense.

Driving up the update frequency on the USB actually doesnt do any good in a CNC application, as i already tried that running a RS485 to USB converted, and a repackaged version of simplemotion c library implemented for linuxcnc.

It works well for driving non realtime critical things like a spindle drive, but should REAAAALLLY be avoided as the use case for motion control. I mean really… reaally shouldnt be considered… there be dragons… and so on.

I will keep digging, do like the Argon drivers, just really dont like using the analog 10V system for controlling them. :slight_smile:

#4

Have you checked the buffered control method?

https://granitedevices.com/wiki/Buffered_motion_stream_in_SimpleMotion_V2

One of our customers built a 18 axis system using the buffered method, and achieved ±3 um accuracy between all axis.

Kind regards, Esa

#5

I have not, and i will take a look at it. Even tho if delays in the seconds would be hazardous and potentially really expensive. But if it can be kept at a minimum, it could still be a viable option.

The whole thing of needing a responsive emergency stop and such needs to work in case of a delay buffer.

I had hopes for the etherfox to be out by now, but i suspect that is in the works and will not be sorted for a while? Mainly we had some luck running analog 10V signal over beckhoff ethercat before, but then we are back to analog signaling and the encoder feedback needs to be splitout and fed back, which causes drift over time and so on.

#6

Question, is there any documentation on the simplemotion protocol ??
As im considering if i can reimplement it as FPGA interface talking RS485 right out of the box instead. And thus be able to cut the communication lag by adding that into the realtime kernel of the cnc controller instead of having it run from userland.

#7

SimplemotionV2 is open source. https://github.com/GraniteDevices/SimpleMotionV2

However the documentation for fpga implementation might not exist / would need some reverse engineering.

#8

Thats too bad… would take forever to translate a C driver into FPGA code to be honest… not impossible just time consuming… :slight_smile:

#9

How about a small cpu on the fpga that would run the app?

But regarding your emergency stop concern, that would be hard wired to the IONI / Argon and would be very responsive.

#10

Not sure what the benefit would be to have a small cpu in conjunction with the fpga, wouldnt that just add a layer of transport communication into the realtime stack?!

#11

Yeah, I agree, it is a crazy idea and kind of defeats the purpose.

#12

Hi

You could ditch the ±10 V commutation signal and replace it with PWM and direction bit. No analog noise anymore, and you could drive it directly from the FPGA.

Also, if you are using incremental encoders, you could read that data by splitting the encoder signals to get realtime position feedback to the controller also.

Kind regrds, Esa