Advanced Search

Which series of drives do you have? If they are fibre-optic controlled, Dmitry has the cleanest, fastest solution to controlling the drives over the SSCNET III/H control fibres.

If they are copper controlled network drives, then Dmitry has a control for that as well, but you can also run the MESA cards for step/direction interfaces.

and some more cross-generation mating... the MDS-E-V2 drive (2024) happily talking to the MDS-A-CR (1995) power supply without any persuation...

It is. I just bought some MR-J3-70B drives, for 29$ per drive, so I guess I'll have to get one of your cards next. Do you have an ethernet driven version? Or just the PCI version?

I hooked up one of the -A copper drives today in step/direction mode, and honestly it isn't that bad to hook up and it worked perfectly, but if I go with the SSCNET system, I can implement more drives without having to add more cables, just extending the fibre interface.

Eventually I'd like to have the tool changer on the SSCNET link as well, and that would be another 200W servo or two.

none. forget the rs422.
ok, you probably can read something out of it with a userspace comp with a limited frequency.. e.g. a torque feedback comes to mind. but i can't imagine anything else. doesn't worth the trouble, imho,

you'll need at least servo-on, step, direction outputs wired to CN1. alarm input is a must. utilizing absolute encoders require 2 more inputs and 3 outputs...

sscnet is so much more convenient...

MR-J3-A (as well as MR-J,J2,J2S,J4,J5-A) drives have generic pulse train position or +-10V analog speed and/or torque control

MR-J,J2,J2S-B - copper SSCNET I/II control interface
MR-J3,J4,J5-B - optical SSCNET III or III/H
MR-J5-G - CC-Link IE TSN over gigabit Ethernet
MR-J5-G-N1 - EtherCAT

I've finally gotten a little time to work on this again!

I'm still planning to use the MR-J3-70A drives, which I have already. What is the current state of support for the copper network drives?

I also ordered some Ethercat boards to play around with it, for now I just use regular Ethernet. I will suspend working on it until after chinese new year since I need connectors.
I also hope I can get hands on more Mitsubishi/possibly other machinery in Taiwan.

Chaining up multiple boards with Ethercat seems to be interesting, especially for the peripheral part.

The Zynq is definitely super powerful, I was able to get away with a microcontroller and accurate timings.
But the MDS-B series only needs 3.55ms framing, not 0.222, jitter is around 20ns (while the measured jitter on the Meldas M65 controller is 40-60 ns .. of course all relatively due to my non certified measurement equipment).
My plan is to make it pretty much modular with Ethercat chaining up various modules for certain tasks.
I want to mix my system with different motors than Mitsubishi for 5 axis support.

I have an old DE2 FPGA board (with ethernet), and a couple of LatticeSemi LFE3/5 boards (also with Ethernet) here which I almost wanted to use for it. I think I will just stick with various microcontrollers and small FPGAs if needed to keep it simple in the future.

MRx, nice! what hardware are you using?

and i'm still working on the new platform, also with an ethernet interface... now i can have all supported mitsubishi protocols running simultaneously on a single zynq 7010 core ok, 5 of them - parallel bus (MR-S), 2 copper serial (SSCNET I, II, MELDAS 5/6), 2 fiber (SSCNET III, III/H, MELDAS 7, 8). as all of them share the same multiple-of-222us cycle time...

still have the second processor core and a spare PTPv2-capable 1Gb ethernet port to try the CC-Link IE/TSN thing to complete the picture...

I have also implemented support for MDS-B-SVJ2 Servos via ethernet. That's the first test. X/Y/Z and the spindle are ok (the video only shows X/Y). I will make some other videos within the next weeks. For a test it's connected via USB ethernet adapter to my notebook (I will move it to a raspberry PI within th next days)

Still quite some way to go .. tool changer, lubrication system, chip conveyor and so on. My Meldas M65 controller had issues with the battery 3 times in a row (and we bought them original from Mitsubishi), everytime the settings are gone we would have to drive to Mitsubishi to put the options in... I'm done with that and move the system to LinuxCNC now.

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 


Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)
 
You are right, I agree with you 100%, main goal is get lcnc with curves at 1khz ... Timig is very wide and difficult topic but faster code means more play to some latency or timig issues of something, stability, rigidity etc...

I think it is reachable timing .. faster tick means better final result of movement and better regulation feedback with velocity or current control.. 

Then we can say isolated cpu to sleep if it will runs at longer timing then 250us .. finally we can use more masters at other network interface to run it with different timing if it is needed and then let cpu to sleep

I think Luca's goal are very very well definied .. from my point of view there is missing just pos(t+1) or pos(t-1) for position commands to any drivers which is not using the velocity setpoint(its cosmetic to not see the ferror during movement with position setpoint)

We can runs 16khz with beckhoff but there is latency restictions... for now... I am running 0.5khz with profibus equidistant and it works well but with trapeziodal its was pain.. now with scurve its smooth like butter... lower timing than 1khz are for gentelmen which they know what they are doing.. its advanced I think
 

Gentelmen, I am sorry for talking about editing and adding the positionCmd(t+1) or positionCmd(t-1) to active creating planner but there is a problem of unsynchronized movement or synchronized(t+-x) motion ... it is common issue of any outsourced position control stuff

if somebody has stuff for example running at ethercat with CSP, he/she will be still in lag for cycle or two cycles(if he/she will not has reference cycle negative) behind stuff at same control master for example CSV which will have PID- with FF1 set to 1.0 ... feedforward compensation will not be present and lagging axis will create(during higher speed motion) unsynchronization and it could influence final shape during some 3d pathing or finishing...  with higher speed it will create higher lag (I am talking about ethercat because I can test it myself at my HW)

this is just my ideas, please let me know your point of view ... 

thanks

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 


Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)
 

You are right, I agree with you 100%, main goal is get lcnc with curves at 1khz ... Timig is very wide and difficult topic but faster code means more play to some latency or timig issues of something, stability, rigidity etc...

I think it is reachable timing .. faster tick means better final result of movement and better regulation feedback with velocity or current control.. 

Then we can say isolated cpu to sleep if it will runs at longer timing then 250us .. finally we can use more masters at other network interface to run it with different timing if it is needed and then let cpu to sleep

I think Luca's goal are very very well definied .. from my point of view there is missing just pos(t+1) or pos(t-1) for position commands to any drivers which is not using the velocity setpoint(its cosmetic to not see the ferror during movement with position setpoint)

We can runs 16khz with beckhoff but there is latency restictions... for now... I am running 0.5khz with profibus equidistant and it works well but with trapeziodal its was pain.. now with scurve its smooth like butter... lower timing than 1khz are for gentelmen which they know what they are doing.. its advanced I think

endian wrote:

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 

Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)

Aciera wrote:

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 

defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and help shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576

do you mean for a spindle? haven't looked at it yet.
i would be surprised if servos have velocity control... or do they?