Why not USB? (again)
23 Dec 2011 22:11 #15971
by doug6949
Replied by doug6949 on topic Re:Why not USB? (again)
I know this subject has been beaten senseless numerous times. I am usually the one holding the biggest stick.
However.......
Tom Kerekes at Dynamotion is using what appears to be a subset of EMC2 as the interpreter for his KFLOP boards. I have not used this product but I do know that Tom is good at what he does.
An associate of mine in Seattle has used this system in three or four router tables with favorable results.
From what I can tell, Tom gets away with a USB interface because the motion planner is on the board. While this is no longer strictly EMC2 it is about as close as it gets for USB.
Doug
However.......
Tom Kerekes at Dynamotion is using what appears to be a subset of EMC2 as the interpreter for his KFLOP boards. I have not used this product but I do know that Tom is good at what he does.
An associate of mine in Seattle has used this system in three or four router tables with favorable results.
From what I can tell, Tom gets away with a USB interface because the motion planner is on the board. While this is no longer strictly EMC2 it is about as close as it gets for USB.
Doug
Please Log in or Create an account to join the conversation.
24 Dec 2011 09:13 #15976
by ArcEye
Replied by ArcEye on topic Re:Why not USB? (again)
This is what Doug is referring to.
dynomotion.com/KFLOP.html
I'll leave others to comment upon whether it is a departure beyond EMC itself.
Clever product though.
dynomotion.com/KFLOP.html
I'll leave others to comment upon whether it is a departure beyond EMC itself.
Clever product though.
Please Log in or Create an account to join the conversation.
24 Dec 2011 09:51 - 24 Dec 2011 10:12 #15977
by cncbasher
Replied by cncbasher on topic Re:Why not USB? (again)
yes Kflop is a totaly different beast, it is a motion controler microprocessor based product , not pc based , there is also a server client between the GUI and the motion controller .
infact if you try, you can switch off the GUI application and the machine will continue to run until the buffer is empty ,thats one of the disadvantages of USB which can show up in real time applications , not the best of worlds with a Machine environment and USB is flawed when it comes to real machine applications , personly i dont like USB for machine applications, i have had too many headaches and late nights solving such problems .
i'd rather use Ethernet anyday than USB ,but thats my view
and yes i do use dynomotion products !, their excellent
infact if you try, you can switch off the GUI application and the machine will continue to run until the buffer is empty ,thats one of the disadvantages of USB which can show up in real time applications , not the best of worlds with a Machine environment and USB is flawed when it comes to real machine applications , personly i dont like USB for machine applications, i have had too many headaches and late nights solving such problems .
i'd rather use Ethernet anyday than USB ,but thats my view
and yes i do use dynomotion products !, their excellent
Last edit: 24 Dec 2011 10:12 by cncbasher.
Please Log in or Create an account to join the conversation.
24 Dec 2011 20:01 #15985
by jmelson
Replied by jmelson on topic Re:Why not USB? (again)
ArcEye wrote:
interpolation and deserializing, not the interpreter, trajectory planning, etc. in the unit.
(That makes sense, especially for a TMS320-based product, those have limited
program memory space.) I also note it says USB Full-speed, which is the 12 mbits/second
interface. I'm a bit surprised by this, it may be a misprint. Given the overhead
of USB, that will get you, MAYBE, 750K bytes/second. Well, maybe for just shipping
blocks of waypoints, that is enough. The problem is that with USB, there is no
guaranteed delivery of packets, so certain system disruptions like plugging in
a memory stick can cause sudden pauses in traffic. That could cause the machine
to suddenly come to a violent stop when the queue runs empty.
Jon
Well, the block diagram seems to indicate it only has the axis PID and some trajectoryThis is what Doug is referring to.
dynomotion.com/KFLOP.html
I'll leave others to comment upon whether it is a departure beyond EMC itself.
Clever product though.
interpolation and deserializing, not the interpreter, trajectory planning, etc. in the unit.
(That makes sense, especially for a TMS320-based product, those have limited
program memory space.) I also note it says USB Full-speed, which is the 12 mbits/second
interface. I'm a bit surprised by this, it may be a misprint. Given the overhead
of USB, that will get you, MAYBE, 750K bytes/second. Well, maybe for just shipping
blocks of waypoints, that is enough. The problem is that with USB, there is no
guaranteed delivery of packets, so certain system disruptions like plugging in
a memory stick can cause sudden pauses in traffic. That could cause the machine
to suddenly come to a violent stop when the queue runs empty.
Jon
Please Log in or Create an account to join the conversation.
24 Dec 2011 21:14 #15986
by PCW
Replied by PCW on topic Re:Why not USB? (again)
750K bytes per second is plenty for a buffered profile (a full multi axis PVT packet set is only 12 bytes per axis with 32 bit parameters so just 48 KBytes/sec for four axis at 1 KHz update) We do this with buffered profiles with SoftDMC but again USB is really not a good transport unless you have a fairly large buffer, but this buffer is contrary to EMCs design, causes more complexity and limitations, and is basically a bandaid necessitated by either non-realtime OS or non-realtime transport..
Please Log in or Create an account to join the conversation.
26 Dec 2011 16:21 #15997
by doug6949
Replied by doug6949 on topic Re:Why not USB? (again)
The intended market for the Kflop is/was stand-alone industrial motion control. CNC was an afterthought to expand the market base. Considering Tom's lack of experience in CNC the end result is commendable.
USB is, in this case, a bridge between firmware CNC and software HMI. That's probably the extent of USB's usefulness in CNC.
It is interesting to note the Kflop plugin for Mach does not use the Mach kernel driver. Perhaps all they are really using of Mach is the HMI and its market base..
Doug
USB is, in this case, a bridge between firmware CNC and software HMI. That's probably the extent of USB's usefulness in CNC.
It is interesting to note the Kflop plugin for Mach does not use the Mach kernel driver. Perhaps all they are really using of Mach is the HMI and its market base..
Doug
Please Log in or Create an account to join the conversation.
03 Feb 2015 19:52 - 03 Feb 2015 20:02 #55634
by engraver
Replied by engraver on topic Why not USB? (again)
Hello to everyone, maybe i've lost 3/4 of the information posted but my english is vary bad (xD). Reading the
HardwareDesign
, i've understood that the problem is that the rt-usb is missing or non implemented.
However, looking for information about USB and realtime i found this link:
rtusb-32
Could be usefull?!
Or if i make me in trouble please be patients and explain me what is wrong.
Have a good day
P.s. after a deep controll i've found a crazy price list O_O
Forgive me for that topic
However, looking for information about USB and realtime i found this link:
rtusb-32
Could be usefull?!
Or if i make me in trouble please be patients and explain me what is wrong.
Have a good day
P.s. after a deep controll i've found a crazy price list O_O
RTUSB-32 Including Full Source Code | EUR 4,500.00 |
Additional Team Member Seat1 | EUR 750.00 |
Update Subscription, Renewal2 | 20% of License Value |
Update Subscription, New2 | 40% of License Value |
Product Update3 | 50% of License Value |
Forgive me for that topic
Last edit: 03 Feb 2015 20:02 by engraver.
Please Log in or Create an account to join the conversation.
03 Feb 2015 21:52 #55645
by andypugh
Replied by andypugh on topic Why not USB? (again)
As you have noticed, this does not seem to be an option as any realtime-USB stack shipped with LinuxCNC would have to be open-source.
There was an open-source USB project on RTAI , but it appears to have been abandoned:
(usb20rt at this link: www.rtai.org/userfiles/downloads/RTAICONTRIB/ )
The Xenomai version looks a lot more active:
sourceforge.net/projects/usb20rt.berlios/
There was an open-source USB project on RTAI , but it appears to have been abandoned:
(usb20rt at this link: www.rtai.org/userfiles/downloads/RTAICONTRIB/ )
The Xenomai version looks a lot more active:
sourceforge.net/projects/usb20rt.berlios/
Please Log in or Create an account to join the conversation.
Time to create page: 0.132 seconds