Bit amused by this.

[Preston_Bannister]

Bit amused by this.

Need to anchor the belt-ends at the “boat” framing the print-head. Coming up with an anchor is not hard, but what is the simplest/lightest solution?

Came up with wrapping the belt around a post, and using printed “teeth” to anchor the last bit. This works … remarkably well. And is simple and light.

Kind of expected to run a screw through the upper end of the clamp. (Wary of the plastic tendency to creep.) But … this might be sufficient.

Not pretending this is an original solution, as I am sure other folk have hit on the same or similar idea, but surprised this works as well.

If you look closely at the CAD model I use for the bit that grips the teeth, please keep in mind my CAD skills are new. It works.

Still need to sort how to tension the belt. A one-tooth delta might be a bit crude, at this point in the assembly. (Guessing the belt-tension should at least equal the maximum torque of the motor.) Have a notion for a tensioner on the back-side of the CoreXY belt run, but not yet to that point.

Oh. The “boat” is a bit light at this point. For the fit-test iterations, I want prints to complete in less time. The carbon-fiber tubes for the XY gantry have arrived, and have another “light” print running…

Oddly, this leads into an apparently dissimilar topic.

I expect to use Linux running on a Raspberry Pi to drive the printer. Seems this has presented some(?) difficulty to folk, before. (Yes, I am long familiar with the notions of “soft” and “hard” real-time, and at least some of the associated complexity.)

Which leads to the question:

How often do I need to drive the I/O pins to support fast prints?

Anyone have a clue to this question?

[Ryan_Carlyle]

Tensioning CoreXY is easy, just slot the motor mount bracket.

Step pulsing depends on what kind of microstepping you want. Finer microstepping = quieter printer. 1/16th stepping is a good minimum. To avoid step doubling (firing two or four or eight pulses at a time so the firmware can keep up) you need:
Speed (mm/s) * steps per mm (usteps/mm)
for EACH axis. So at 300 mm/s and 1/32 stepping of a 16t GT2 pulley on a 200 steps/rev motor that’s 30020032/(16*2) or 60 KHz.

Then what kind of DDA and pulse generation do you want to use? The usual method with bare metal firmware is some quantity of interrupt timers. Maybe all axes are on a shared interrupt timer (e.g. Bresenham’s in Marlin). Maybe the extruder is on a separate interrupt so you can implement Pressure Advance algorithms (e.g. Sailfish). Maybe the next step pulse time is calculated after every step (e.g. RepRapFirmware) and one interrupt timer is constantly reset each time. These schemes tend to cap the step pulse generation rate. Marlin can handle about 10KHz. Sailfish about 8800 Hz with the same AVR processor because it’s doing more interrupt calls. Over those limits, you have to fire multiple step pulses per interrupt. This effectively reduces the microstepping level of the driver. (Four 1/16 steps is the same as one 1/4 step.) So the motors run rougher and might lose torque or hit resonance.

MachineKit, your closest analog for RPi Linux development, instead uses a 1000 Hz servo loop, which runs a PID for each axis to control an output frequency instead of firing individual times pulses. Every servo loop tick, it checks whether the fired pulse count is on target for the desired motion and adjusts the frequency as needed. If frequency generation can be offloaded to a PRU or FPGA or Mesa card, this works quite well. If the CPU/OS has to output the frequencies itself, it can be very high jitter. There’s also the risk that a software freeze causes the frequency generators to stay live and drive the machine to self-destruction. You have to think about that kind of stuff.

[Preston_Bannister]

@Ryan_Carlyle First, at this point I do not know what I am talking about, as I have not (as yet) visited that aspect of the subject in detail. So I could be badly wrong about all of this.

Second, assuming we have to update the hardware 10000 times per second (which sounds excessive), that means I have 120000 clock cycles (on a single CPU) to update some I/O ports. I have done a lot more with a lot(!!!) less.

The math you are talking about may sound complicated, but keep in mind the math for each step can be radically(!) less. Interpolation is old stuff. A plain nothing-special CPU is going to do just fine.

I could be wrong, but in the domain of software algorithms, I suspect we are not in any trouble.

What is outside my area of knowledge is microstepping. Someone else in this group (thanks) pointed out Keith’s work.

http://www.openbuilds.com/builds/trueup-kit-version.4779/

As Keith states “microstepping was developed only for smooth motion, not for accuracy”. If true, then microstepping should only be used when you have sensors to verify actual position.

[Mark_Pappin]

@Preston_Bannister

“microstepping was developed only for smooth motion, not for accuracy”

As I understand it, microstepping gives you smoother motion but no increased NOR DECREASED accuracy or precision - if your sequence of microsteps ends at a full-step position, the motor will stop at the same place it would have under full-step control. Thus microstepping is a net win.

[Ryan_Carlyle]

There’s a ton of myths online about microstepping. If you don’t understand the way steppers generate torque as a function of position error, you’re not going to understand microstepping.

The simple truth is that finer microstepping is always better, subject to pretty strong diminishing returns. The only time you ever LOSE anything with finer microstepping is when the motion controller processor can’t keep up with the step pulse rate.

As a general rule:
1/2 to 1/8 - adds resolution, improves smoothness, reduces resonance, increases torque slightly, reduces audible noise
1/16 to 1/32 - slight improvement in smoothness and resolution if loads are small, reduces audible noise
1/64 to 1/256 - reduces audible noise
Over 1/256 - pointless

[Ryan_Carlyle]

@Preston_Bannister if you want to print fast with a standard stepper driver type arrangement (versus some other motor control scheme) you’re going to need to toggle IO pins at something resembling 1 MHz, with very precise timing. People who print fast with typical printer controllers routinely run into 40, 50, 80 KHz step pulsing limits of those controllers. Let’s call it 100,000 pulses per second so you’re actually pushing boundaries. That’s pulse frequencies for each motion axis. Each of those has to be toggled high, held long enough for the pulse to be read by the driver, and then toggled low. So for four motion axes now you’re up to as high as 4100,0002= 800,000 IO ops per second. And those may be out of sync (depending on how you interpolate) so you’re going to run into beat frequencies where they all need to be fired back to back. And you need to fire all these pulses with less than, say, 10% timing jitter (which is quite bad) so the processor needs to be able to check whether to fire a step at a very, very high frequency if you’re not running a hardware interrupt timer.

When you stack all this stuff up, a naive motion control implementation can easily cream a low-power processor or run afoul of OS management activity and end up having serious hangs.

It’s doable, you just have to know what you’re doing.

[Baldur_Norddahl]

@Preston_Bannister I am not sure about the RPi cpu but on cpus like ones in a real computer the bottleneck is memory bandwidth. Not cpu cycles. On each context switch or interrupt a lot of stuff needs to go to and from memory. Sure the cpu cache will help but even that has far less bandwidth than clock cycles.

[Preston_Bannister]

Thanks. @Ryan_Carlyle , Mark Pappin, and @Baldur_Norddahl - any clue as to what to look for in the upcoming exercise is welcome.

Ryan, the 1 MHz number sounds high. Physical things rarely move that fast, and at best we are talking about a print head moving at a few hundred millimeters per second.

In fact, the “shields” that attach to these small boards … how often will they accept updated inputs? (I have no notion, as yet.)

Keep in mind the notion of “code-hoisting” from the old supercomputing folk. Re-computing your plans on every step is expensive. Pre-computing your plans in batch can be hundreds (or thousands) of times more efficient.

(And a Raspberry Pi 3 has quad CPUs…)

I used exactly this approach to get a 4:1 interleave out of an early Western Digital WD1000 disk controller in the early 1980s. (This was my first job out of college.) Then the legendary IBM assembly language programmers were unleashed on the next-generation (much smarter) controller. They had a faster CPU, a faster bus, faster DMA, and a much smarter controller … and managed a 12(?):1 interleave.

Algorithms win.

I have done quite a lot of this sort, in the years between.

[Ryan_Carlyle]

Yeah, but it’s seriously not a matter of clock cycles, it’s a matter of timing. A millisecond delay is HUGE here. It’s an application where you’re aiming for <0.01mm errors and trying to move at 300-1,000 mm/s (if you want to be considered “fast”) so you’re talking about needing to hit the low tens of parts-per-million level timing accuracy.

Yes, 100 KHz step frequency per motor is completely realistic, not even pushing the bounds really (I do 70 KHz today on multiple printers) and when you have to synchronize four of those, there are ways of doing it that require the CPU to handle MHz level IO update speeds. There are also ways of doing it that dynamically scale the step pulse requirements to go easy on the processor, which is why we have 8bit 16Mhz processors today that can run at 250 mm/s. I’d personally recommend you go read code for a while to see how this is done after thousands of man-years of development of MachineKit or Marlin or Smoothie.

[Daid_Braam]

Marlin on the AVR tops out at 40Kilo steps per second, and then it’s using quad stepping (4 steps per interrupt)
I’ve done 200Kilo steps per second on an ARM based controller running at 84Mhz. Without any double/quad stepping.

Running stepping directly from an multi core Linux platform? You will be in a world of pain. RTLinux can help. But you really want to “out source” this to something that doesn’t have the timing issues of cache, other interrupts.
The beaglebone PRUs are a possible candidate for this for example.

[Ryan_Carlyle]

Yes, Beaglebone is a good solution here, which is why there are already multiple 3D printer controllers that use it