|Thread: Arduino Gear Hobber|
Posted by Joseph Noci 1 on 29/07/2020 13:24:24
Posted by Robert Atkinson 2 on 29/07/2020 13:01:41
One way to improve performance of these systems is to combine hardware and software. Use hardware ro keep track of the encoder(s) and software to do the clever bits. When doing this sort of things for the day job we used HP/Avago/Broadcom encoder interfaces like thw HCTL-1100 and HCTL-2020. Now for critical counting applications I use Microchip PICs with built-in hardware counters and dividers. They also do versions with encoder interfaces built in. See http://ww1.microchip.com/downloads/en/DeviceDoc/70208A.pdf
Sone of the Atmel (now Microchip) chip range used in Arduinos have hardware encoder interfaces but I'm not an Arduino user so don't know if the specific chips are used or supported by the development environment.
That is true to some extent Robert. It depends on what the 'divisor' method is that you wish to implement.
Since the objective here is to keep the stepper pulse rate AND TIMING synchronized to some relationship to the incoming encoder pulses, you cannot just let the hardware counter accumulate the encoder pulses and then get to them 'later' - in the meantime you were supposed to generate stepper pulse so you lost the plot...
Synchronized operations like this require real-time software response - and the definition of real time is any time as long at the software keeps up with the execution rate required.
This is actually how linuxcnc works with external interface hardware. (not a motion controller as the motion controller is in software - linuxcnc) The external hardware just does the stuff computers don't do well (fast encoder counting, High speed step generation, Pwm generation and such) Linuxcnc is running a realtime thread that polls the external hardware every 1ms (or 500us or whatever the system can handle) It gets the encoder counts, sets pwm levels, sets step rate and so on. This works very well. (as a cnc controller and hobber as others have shown)
The other thing you get with with a computer running linuxcnc - floating point calculations. (this is the stuff the computer does well)
Posted by SillyOldDuffer on 28/07/2020 16:04:08
Posted by Bazyle on 28/07/2020 14:26:55
The first problem with most of the micros with a 'high level' operating system is that they don't tell you that they go off and do their own thing every few milliseconds which interupts the flow.
Coincidently I've been looking at the possibility of using a RaspberryPi 3 or 4 and Rasbian Linux as a microcontroller. Advantages: a real operating system, multi-core 64 bit CPU, built-in GPU, FPU, wifi, usb, print support etc and cheap. The CPU in a Raspberry is considerably more powerful than both Arduino and Nucluo. Disadvantages: limited number of IO pins (about 40), delicate interface electronics, no easy access to hardware interrupts, and the default Completely Fair Scheduler (CFS) that causes Bazyle's impossible to predict interruptions.
CFS is the main problem: it's designed to share multiple tasks across multiple cores such that tasks don't get stuck. Basically tasks run in a time-slice allocated by the operating system and return to the queue when time runs out or they stop for any reason such as waiting for a disc drive. Tasks are restarted by CFS in a fresh time slice when whatever it's waiting for is available, or it rises to the top of the queue again. Although there's some notion of priority, the scheduler pays lip service to it, unless it's reduced! (You can volunteer to stay at the back of the queue.) Anyway, given a queue of tasks waiting for a time slice, CFS selects the task which has least time on the system so far and everything gets a fair crack of the whip. Works very well except when a program must run to a timetable or respond immediately to events. This sort of task needs to stay at the top of the queue without being mucked about by routine business!
The ideal answer is a Real Time Operating System, and there are some for the Raspberry for those with time to investigate. Bit too specialised for me. However, newer Linux Kernels come with scheduler options that might be 'good enough' for embedded work. The Deadline Schedule gives favoured tasks the priority they need to meet a deadline, FIFO does First In First Out, and Round Robin is FIFO with time slices. All these options override CFS and allow tasks to queue jump and dominate. Unfortunately they can't take the system over completely because Linux has other essential jobs, but - on a multicore CPU - they get close to running continually, behaving rather like a fast embedded microcontroller with short glitches.
The open question is, can a linux program with 4 cores available and top scheduling priority do better than an Arduino? Worth a try I think.
Not recommending Raspberry for John's Hobber. Nucleo is a very good choice if faster than an Arduino is needed, and the programming can be very similar.
I have been playing with linuxcnc on the RPI 4. Linuxcnc requires a realtime kernel. (in this situation - rt_preempt)
The thing with linuxcnc is you get a whole bunch of realtime building blocks. Like step generators with vel and acc limits, pwm generators, logic and tons of other pre-built realtime components. (plus you can make your own)
All of these components have been tested and are done
This was done on a RPI 4 With a custom realtime component - slaving the axis to spindle rotation. (well - most all the latest videos about the green machine are done with the rpi)
Just a thought. Sir John did a bit of work on gear hobbing and ended up using Linuxcnc... You could even start with the printer port... It is a cool platform/framework that allows for a ton of easy development.
|Thread: Emco servo conversion - compact 5 cnc|
That was all by hand gcode. The actual polygon turning is currently done by sending info to hal layer from gcode.. I hope to do a remap but I am not there yet. So something like (this is on the mill - polygon boring)
(number of sides)
(Cutter diameter - probably get from the tool table in the future)
(rotate poly 0deg)
(enable polygon component)
(disable polygon component)
more close up action...
Posted by Dave Smith 14 on 13/07/2020 08:48:08
Great result, but please keep your fingers away from the moving parts even a small machine will take a finger off.
Agreed - I was unprepared for the first run of the program.
some machining required...
A bit of an update
Posted by John Hilton on 21/05/2020 07:26:57
I presume you are using service motors fitted with encodes?
What encoder interface have you used?
Yes - some Pitmann servos that came with 500 line encoders. I am using Mesa interface hardware that does the high speed pwm and encoder counting. (5i25) which acts like 2 super high speed printer ports. (expandable - you can get daughter boards that do all kinds of cool stuff - analog servos, steppers and such)
I am using it in kinda unconventional way (think cheap a$$) (mesa + cheap bob)
addendum... There was a setting in the ini file that was capping the acceleration at 6in/sec^2.. No wonder why it looked so good. So - upping the acceleration to 50in/s^2 I get a peak following error of .0002" (10 encoder counts - which is exactly what I would expect) Now it feels as expected - accelerating to 150ipm is pretty instant.
I finally got back to the Emco project after a few years. Squirrel! I had thrown it together trying out some pwm drives I had - which seem to work great. When I started pllaying with the spindle I started getting noise. (sporadic estop pulses). (mainly because in my excitement of the servos working well - I didn't pay much attention to grounds..)
So - Taking the time to do it right.. (I want a little lathe to test the polygon turning..)
Currently the servos are tuned with a max following error of .00007", acceleration of 40in/sec^2 and top speed of 150ipm. Very happy with this - and it looks like I could up the acceleration.
|Thread: non-circular boring.. Literally - it is boring!|
This is the latest code for linuxcnc
Greenslands - replied - what control are you using?
Actual spinning encoder. (thought I put this in another video..)
Posted by Thomas Dye on 10/05/2020 16:19:55:
I see that continuous stream of chips and wonder how difficult it would be to add chip breaking in the g code?
Would definitely stop them building up around the tool.
I suppose it could be done by alternating the path or by over-boring the hole slightly first.
Other than the spindle synced motion - the gcode is normal. You could do a pause every so far..
I think I get a D for effort...