Low cost multi-axis motion controller

Tinine

Member
Join Date
Oct 2022
Location
Lancashire
Posts
127
Hi folks,


We have been working on our own controller after many decades of using the "big names".


What would your ideal motion-controller be capable of?
Our top priority has been user-repairability. We have dubbed our concept MTTR-ZH (mean time to repair zero hours).


We've had decades of supporting the likes of "big auto"...we don't like downtime, nor do we like closed source.


Rgds,


Craig
 
If you want to keep the costs low you need to support only what your application requires. If you are trying to make a general controller then you will always be asked to add one more feature which raises costs.


We have the capability to design MUCH cheaper controllers that what we do now but what feature do you want to remove. Supporting Ethernet like Ethernet/IP, Profinet, and Ethercat are out of the question as they take too many man hours to implement. Without Ethernet you can't have the nice plotting routines. This makes tech support difficult which will raise the cost. What we have done is made a full feature motion controller with all the bells and whistles. I would only consider making a cheap controller for an OEM that might sell 500+ a year for many years. This way once they get the motion controller to go it is just repeating the same old thing. Fancy debug tools are required.


BTW, what really p$sses me off about customers is that they are so eager to blame the motion controller that has been used in many 10s of thousands of applications and their one off machine couldn't possibly be at fault.


Don't sell cheap controllers to people that make one off machines.
 
Hi Pete,


Man, do you ever sleep?



Well, low-cost doesn't need to be "cheap".


The wonderful thing about standards is that there are so many to choose from....wait, what?


No. All field bus systems are out of the question. The idea is for Joe-maintenance-guy to be able to troubleshoot with a DMM. More and more, all they can do is pick-up the phone and call for outside help, sometimes wait days or weeks only to find that they require a replacement widget that went EOL, several years ago.


Need to get away from this nonsense.


Rgds,


Craig
 
What kind of motion controller are you talking about specifically?

My automotive experience is that diverse capability and lesser number of spare parts is important as the company views spare parts as dead-weight. Say 12million dollars that would be better spent generating revenue directly.

If the part is twice as much, but we only require 3 spares vs 25 for subtle variations between each kind then go with the 3 that cost twice as much all day.

It runs counter to the penny pinching that goes on with designing and quoting of a machine for a customer so you can provide a competitive price.

As a whole it's just easier to have a one-stop-shop solution, but I do realize for more specialized applications a specific part may be a good savings.
 
What kind of motion controller are you talking about specifically?

My automotive experience is that diverse capability and lesser number of spare parts is important as the company views spare parts as dead-weight. Say 12million dollars that would be better spent generating revenue directly.

If the part is twice as much, but we only require 3 spares vs 25 for subtle variations between each kind then go with the 3 that cost twice as much all day.

It runs counter to the penny pinching that goes on with designing and quoting of a machine for a customer so you can provide a competitive price.

As a whole it's just easier to have a one-stop-shop solution, but I do realize for more specialized applications a specific part may be a good savings.


Closed-loop servo:


Motor command: +/- 10v or PWM+Direction (both 16bit)

Feedback: Incremental Encoder. Main and Auxiliary for dual-loop, no practical frequency limit (quad counters are sysclk/2)


Parallel processing, no interrupts required


Three independent interpreted BASIC (self-hosted) PLCs, each with a Mikroe Click socket for further expansion.


Two Click sockets on the parallel processor


Position latch at any speed


No need for slow index-pulse searching when homing


Encoder failure detect


All PID loops down to a few microseconds


Position range selectable 32bit or 64bit


Spares:

It's a hard-sell to the bean counters and so you simply include them on the inside of the enclosure. Socketed buffers (opto-couplers, line transceivers and even a binary-loaded CPU.)
These components cost nothing anyway.


Rgds,


Craig
 
No. All field bus systems are out of the question. The idea is for Joe-maintenance-guy to be able to troubleshoot with a DMM. More and more, all they can do is pick-up the phone and call for outside help, sometimes wait days or weeks only to find that they require a replacement widget that went EOL, several years ago.


Need to get away from this nonsense.

I think this would be your biggest obstacle.

Having serviceable parts is fantastic, Love that.

You or your customers having infrastructure necessary to make them capable of self-support is hard and may lead to a lot of travel and late-night calls when they aren't up to the task.

Board-level understanding, capability, or even willingness to troubleshoot is hard to come by these days, and the industries I've been exposed to have mostly leaned into the throw-away mentality. I also don't think tech schools are offering much opportunity to learn it from an on-the-job perspective.

Not trying to rain on your parade, just speaking from my experience about what I've encountered in industry. One of my previous employers we used an off-brand application specific motion controller, and for the most part it was fine, but trying to interface with it if you had a deeper issue required external (European time) support because there was no training, and not something where you could use commonly known software tools. Now the controller worked well, and we had many of them, and I can only recall one instance of this, but that's probably best-case scenario.

We eventually ended up bringing in a brand of controllers that used a common control system which we were prepared to troubleshoot, and I think it was actually cheaper.
 
I think this would be your biggest obstacle.

Having serviceable parts is fantastic, Love that.

You or your customers having infrastructure necessary to make them capable of self-support is hard and may lead to a lot of travel and late-night calls when they aren't up to the task.

Board-level understanding, capability, or even willingness to troubleshoot is hard to come by these days, and the industries I've been exposed to have mostly leaned into the throw-away mentality. I also don't think tech schools are offering much opportunity to learn it from an on-the-job perspective.

Not trying to rain on your parade, just speaking from my experience about what I've encountered in industry. One of my previous employers we used an off-brand application specific motion controller, and for the most part it was fine, but trying to interface with it if you had a deeper issue required external (European time) support because there was no training, and not something where you could use commonly known software tools. Now the controller worked well, and we had many of them, and I can only recall one instance of this, but that's probably best-case scenario.

We eventually ended up bringing in a brand of controllers that used a common control system which we were prepared to troubleshoot, and I think it was actually cheaper.


What prompted me to bring this up was an automotive supplier in the UK-midlands. We retrofitted a piece of equipment some years ago with a motion-controller and an Android front-end. This has inspired them to migrate from conventional PLCs to microcontrollers that are commanded via Android tablet-based Node-Red. They tell me that they have really taken to it but I agree, very few seem to be interested in getting involved in such things.
I understand what they go through....a replacement Simatic or Beckhoff HMI £4K if you can get one, Profibus encoder, 6-weeks delivery. This stuff kills entire production lines.


Rgds,


Craig
 
I had same situation with EOL siemens HMI's and it was infuriating. Ended up buying them on ebay or various resellers every chance we had.

The root is nobody wants to take the downtime necessary to upgrade an existing system to something current. "It still works *shrug*" and then some poor SOB is the one trying to keep things in operation with no time to maintain or service it. T1 automotive is BRUTAL.

The brand we rep at my current role has a new controller with node red capability, but thus far we've used it exclusively for data collection tasks. There's even ability to bridge directly to other control systems and allow you to convert it to a webserver runtime since during covid it was damn near impossible to get parts.

Webserver runtimes are the way to go IMHO, cheap android tablet is 100$ vs 3-5k$ for an antiquated big-name HMI let alone the software to interface with it.
 
I had same situation with EOL siemens HMI's and it was infuriating. Ended up buying them on ebay or various resellers every chance we had.

The root is nobody wants to take the downtime necessary to upgrade an existing system to something current. "It still works *shrug*" and then some poor SOB is the one trying to keep things in operation with no time to maintain or service it. T1 automotive is BRUTAL.


:ROFLMAO: You arrive at stupid-o-clock to be greeted as the savior but if you don't fix it in 5mins, all of a sudden, you're to blame for the downtime


The brand we rep at my current role has a new controller with node red capability, but thus far we've used it exclusively for data collection tasks. There's even ability to bridge directly to other control systems and allow you to convert it to a webserver runtime since during covid it was damn near impossible to get parts.

Webserver runtimes are the way to go IMHO, cheap android tablet is 100$ vs 3-5k$ for an antiquated big-name HMI let alone the software to interface with it.


We use an amazing open-source BASIC interpreter for the Android HMI and the end-user gets full source-code, in case they want to make changes in the future. Child's play.
As a demonstration, I factory reset the Android (rugged) tablet and show the machine running in minutes. Damaged tablet? Run the app on your Android phone....almost no downtime.


The most ubiquitous, powerful/capable HMI ever created.


It's a conspiracy I tell ya...The traditional suppliers just want you tied-in to their eco-system for ongoing revenue.
They sucker engineers in to believing that throwing Gb of data around in an ocean of PWM-induced EMI is a good way to go "we save on wiring costs".... give - me - a - break! JMO :ROFLMAO:


Rgds,


Craig
 
Hi Pete,


Man, do you ever sleep?
Yes, but sometime old folks have trouble sleeping for more than 4 hours at atime.

Well, low-cost doesn't need to be "cheap".
I am talking about hardware and minimal software time till product is ready.

The wonderful thing about standards is that there are so many to choose from....wait, what?
You haven't defined what you want yet.
A good target generator takes time to develop but it isn't necessary if synchronized moves aren't required.
What time of feedback do you require? Analog is easy and cheap but subject to noise.

No. All field bus systems are out of the question. The idea is for Joe-maintenance-guy to be able to troubleshoot with a DMM.
That pretty much means analog in and out except for a few I/O for run/stop and error.

More and more, all they can do is pick-up the phone and call for outside help,
Yes, and what are they going to say. It doesn't work doesn't mean much. Diagnostics are important but add to the cost.

sometimes wait days or weeks only to find that they require a replacement widget that went EOL, several years ago.
You can still buy motion cards we designed in 1986.

Need to get away from this nonsense.

Unless you can find a high-volume customer, you won't make any money.
I know, I have seen the US market consolidate around a few names. There used to be many small manufacturers of servo hydraulic controls, now there are few and most are going after niche marketers. However, we have not be able to penetrate the mobile market much because the necessary controllers must be cheap and have high volume to make up for it.

I need to show a picture of a small controller we developed years ago and never when to market. It was done in two weeks. It had 2 16 bit analog inputs and 2 12 bit outputs and 2 10 bit inputs for differential pressure/force control. It had a 4x16 LCD display a knob for incrementing and decrementing values and two buttons for select/OK and escape/return. Now I would use a cell phone for the display with blue tooth and upgrade the microcontroller to an ARM chip as they are cheap now. We have the interface to a cell phone, iPad or fire tablet already done. We are just sitting on it.
 
Yes, but sometime old folks have trouble sleeping for more than 4 hours at atime.


I am talking about hardware and minimal software time till product is ready.


You haven't defined what you want yet.
A good target generator takes time to develop but it isn't necessary if synchronized moves aren't required.
What time of feedback do you require? Analog is easy and cheap but subject to noise.


That pretty much means analog in and out except for a few I/O for run/stop and error.


Yes, and what are they going to say. It doesn't work doesn't mean much. Diagnostics are important but add to the cost.


You can still buy motion cards we designed in 1986.



Unless you can find a high-volume customer, you won't make any money.
I know, I have seen the US market consolidate around a few names. There used to be many small manufacturers of servo hydraulic controls, now there are few and most are going after niche marketers. However, we have not be able to penetrate the mobile market much because the necessary controllers must be cheap and have high volume to make up for it.

I need to show a picture of a small controller we developed years ago and never when to market. It was done in two weeks. It had 2 16 bit analog inputs and 2 12 bit outputs and 2 10 bit inputs for differential pressure/force control. It had a 4x16 LCD display a knob for incrementing and decrementing values and two buttons for select/OK and escape/return. Now I would use a cell phone for the display with blue tooth and upgrade the microcontroller to an ARM chip as they are cheap now. We have the interface to a cell phone, iPad or fire tablet already done. We are just sitting on it.


Hey Pete,


At the risk of sounding like a kiss-a$$ (I am not) I mainly lurk on this forum because of yourself and those who follow/debate/argue with you. I just live/sleep/breathe motion control which is weird I know. Why is this stuff so fascinating? :ROFLMAO:


To your point...I don't care about making money. I made it and news flash: It ain't that great!


No. I want to bring back some sanity and independence to the industry. I see what's happening and it's total horse doo-doo. Most don't care because they're spending someone else's money plus the fact that; if they become proficient in one of the BS technologies, they enhance their resumes.



I have always been an employer and I sensed when this cr@p was creeping in and I killed it on the spot.


My philosohy: If it ain't broke, break it anyway...there's always a better solution.


I happen to be credited with "the father of the all-electric CNC tube bending machine" and sure-enough, the patent is mine. BUT as a realistic engineer, I am the first to say that it's total ********. I remain a huge fan of servo hydraulics because a cylinder lasts an awful lot longer than any roller-screw and homing in on +/- 1bit of encoder count is more meaningful when it comes from the load instead of the back-end of a motor. Right?


Rgds,


Craig
 
Yes, but sometime old folks have trouble sleeping for more than 4 hours at atime.


I am talking about hardware and minimal software time till product is ready.


You haven't defined what you want yet.
A good target generator takes time to develop but it isn't necessary if synchronized moves aren't required.
What time of feedback do you require? Analog is easy and cheap but subject to noise.


That pretty much means analog in and out except for a few I/O for run/stop and error.


Yes, and what are they going to say. It doesn't work doesn't mean much. Diagnostics are important but add to the cost.


You can still buy motion cards we designed in 1986.



Unless you can find a high-volume customer, you won't make any money.
I know, I have seen the US market consolidate around a few names. There used to be many small manufacturers of servo hydraulic controls, now there are few and most are going after niche marketers. However, we have not be able to penetrate the mobile market much because the necessary controllers must be cheap and have high volume to make up for it.

I need to show a picture of a small controller we developed years ago and never when to market. It was done in two weeks. It had 2 16 bit analog inputs and 2 12 bit outputs and 2 10 bit inputs for differential pressure/force control. It had a 4x16 LCD display a knob for incrementing and decrementing values and two buttons for select/OK and escape/return. Now I would use a cell phone for the display with blue tooth and upgrade the microcontroller to an ARM chip as they are cheap now. We have the interface to a cell phone, iPad or fire tablet already done. We are just sitting on it.


All of these features are dead easy and I want everyone to know. I remember some of your previous posts where you cautioned that velocity profiling is a challenge or a profile where slew might not be achieved or an early abort from an acceleration might be required. I don't have your math-skills but this stuff is pi$$ easy.


Many years ago, you published a beautifully elegant s-curve algorithm...it works a treat but then several years later you published some horrendous math :ROFLMAO:
No. Your simple version works beautifully :ROFLMAO:


Rgds,



Craig
 
Last edited:
My interpretation, simulated in MicroMite BASIC (awesome, BTW)


Code:
dim as integer isp

ramp_segments = 1/500
res = 500

sync 2,M 'simulates a 2mS update
strt = timer
for  samptime = 1 to res step 2
  sync
  frac = samptime*ramp_segments

  f=(3-2*frac)*frac*frac

  intspeed = f * 2000
  print frac, intspeed
next
fini = timer

print "Time = ", int (fini - strt)
 
Yes, that third order spline or curve works well for simple moves but what happens if the user needs to change the motion profile on-the-fly? This is one reason we dumped the sinusoidal ramps and went to 5th order ramps. It is possible to change the destination or velocity changes on-the-fly. Sawmill applications often require changing the target trajectory on-the-fly. The have been some rotary shear application that do this to.

The RMC has user programs that are written in ST and organized into steps or state. The RMC forces you to use a state machine. In the end it is simpler debug.

Most on this forum have figured it out that math is no obstacle to me. The motion target generator is the most complicated part of a motion controller. The control theory part ( PID ) is simple by comparison yet people seem to get this backwards.

I am retired now but I still visit Delta a few times a week. I still do a MS Team video call to our guy in Edinburgh once a month just to see what is happening in the UK.
BTW, I like watch Jeff Taylor on YouTube so I keep up with the nonsense in the UK.
Why? Technically I now have a king.
 
Yes, that third order spline or curve works well for simple moves but what happens if the user needs to change the motion profile on-the-fly? This is one reason we dumped the sinusoidal ramps and went to 5th order ramps. It is possible to change the destination or velocity changes on-the-fly. Sawmill applications often require changing the target trajectory on-the-fly. The have been some rotary shear application that do this to.

The RMC has user programs that are written in ST and organized into steps or state. The RMC forces you to use a state machine. In the end it is simpler debug.

Most on this forum have figured it out that math is no obstacle to me. The motion target generator is the most complicated part of a motion controller. The control theory part ( PID ) is simple by comparison yet people seem to get this backwards.

I am retired now but I still visit Delta a few times a week. I still do a MS Team video call to our guy in Edinburgh once a month just to see what is happening in the UK.
BTW, I like watch Jeff Taylor on YouTube so I keep up with the nonsense in the UK.
Why? Technically I now have a king.


Having read the documentation for the Galil, PMAC, RMC, Trio, etc., they all have the same limitation which is having to cooperate with the real-time system...time-sharing.


Our approach is 8 X 32bit parallel processors that share the same memory and I/O. No interrupts and therefore no latencies and no jitter. The trajectory generator has a CPU all to itself and running a 500Hz loop (copied that from Galil), it spends most of its time twiddling its thumbs.
State machines, absolutely (there was a time when I thought I'd invented this concept :ROFLMAO:)
In the Accel state, for example, I might be say 4 samples in and a change might occur. Simply recalculate the profile (checking for silly values) and then for the 5th sample, pick-up on the new profile. The output is stuffed into shared memory and the CPU that does nothing but run the PID's picks-up on this new command. Performance anxiety? We're immune to it.


I see that the other guys run their PLC tasks on whatever clock cycles are left-over from running the motion tasks...nope, we have another separate CPU that can respond in nanoseconds.


I was just reading about a case of a BeckHoff Twincat, 1.4GHz Windows-based IPC and 4-axes of motion, dragging the IPC to its knees...:sick: Maybe it's something in one of those endless gobbledegook menus that they have set wrong :D


Yeah, I sometimes watch Jeff...he's always on it. I haven't watched a TV in over 15 years and I avoid all mainstream propaganda so I rely on a few other sources for factual information. I do have a problem with "Dr." John Campbell though. I told him that he was wrong from the outset and today he has done a complete 180 and is clearly seeking redemption :angr:


Not my King, BTW. He was too darned friendly with Jimmy Saville.


I identify as Conspiracy Theorist and my pronouns are: Told-You-So



Rgds,


Craig
 
Last edited:

Similar Topics

I'm a beginner in the automation field and I've set up an automation system connecting several devices (datalogger, radio, etc.) via Modbus RS485...
Replies
5
Views
215
I was wondering if any one had an idea how I could implement an amperage reading to the plc. I have two PWM valves which draw about 3 amps...
Replies
3
Views
1,630
Hi guys, May I ask if you know of any device with as few as 3 inputs and capable of ethernet connectivity? I have a project to monitor a number...
Replies
20
Views
6,877
Greetings, I am looking for some ideas on low cost VFD's which natively support Ethernet I/P. Looking for 3 phase, 480V, 2h.p. and less. Just...
Replies
32
Views
10,647
Hi everyone I'm in the process of automating my home brewery. To get control of levels i was thinking of measuring the flow of water into the...
Replies
7
Views
9,002
Back
Top Bottom