Controller board prototype - forum input wanted

[Mikael Bohman]

I'm drawing a "shield" to this board.

xCORE-200 eXplorerKIT

which I already have. 

I have written some code and the GCODE transfer over USB together with openpnp using USB-CDC seems to work.

My idea is to define a large vector for each stepper which contains int A_MAX *  unsigned char a_max[v] , and solve it for every microstep.  (a = acceleration | v = velocity)

It means that I can have 255 different levels of acceleration between 0 and A_MAX for each velocity between 0 and V_MAX;
The cool thing is that it can map up that vector itself by iterations, and checking against the end-stop if it slipped or not. 

 Home to endstop;

while( NOT ENOUGH VALUES TESTED){

   Move away from the endstop with 50% of an a[v] that is proven to work in an earlier step.

  Increases the acceleration and go back the same distance. 

  Counts the steps before the endstop signals.

  If( no slip) 

    update the vector and go faster the next run

  else

   try different a[v] settings.

}

Each stepper has it's own hardware thread/(XMOS core) allocated to it, meaning interrupts will not be used at all.

An analogy to an Intel CPU would be that it is a dual core CPU with 8 hyper-threads for each core but it never uses interrupts, only events).

This approach doesn't guarantee that a X-Y move using 2 steppers simultaneous will be completely straight from point A to point B, but it should not matter in this case !?

I have only played with the X axis so far with an veroboard connected to the TILE I/O.

Now I need an shield with all the outputs I need for my pnp machine.

So far I have:

Output for X , Y0 , Y1 stepperdrivers, which are external 2DM860H and feed with 42V AC.

Z, C0 , C1 are AMIS-30543 drivers soldered directly on the shield (24 V DC). With SPI control and with up to 128 steps of microstepping.

4 endstops for X, Y0 , Y1 , Z

8 MOSFET output , with up to 3 different rails.

2 half H-bridges (MOSFET) with advanced PWM / Delta-Sigma support from a XMOS thread.

2 vacuum sensors with 12 bit A/D over I2C; (0 - 100 kPa abs. p)

One 12-bit A/D over SPI for load angle feedback for the Z axis stepper.

Header for I2C and SPI, and 4 extra GPO pins.

And it should fit the ALLPCB 10 cards for 5$ offer.

The blueish card in the bottom is the XMOS card with USB 2.0 and gigabit Ethernet.
The whitish card on the top is my shield.

Am I missing something important- maybe something for future feeders?

Other thoughts ? 

(My smoothie-board will be used to my 3D-printer that I'm currently building if it works the way I want it to do).

[Mikael Bohman]

Missing: A connector for an external killswitch button.

[Matt Brocklehurst]

That’s pretty cool I’ve got a few Xmos dev boards been wanting to find a use for them :)

Have you done the acceleration curve implementation yourself? Or are you porting something like grbl to Xc?

Sent from my iPhone

On 4 Aug 2017, at 00:02, Mikael Bohman <bohman...@gmail.com> wrote:

Missing: A connector for an external killswitch button.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/008d5946-b368-48a2-a5d7-9674e77024da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mikael Bohman]

Not based on grbl.  

I will not support arcs, deltas-robots etc.  Only the G codes needed for openpnp with an X, Y, Z machine.

A simplified XC code for each stepper thread would be:

//Using port timers

v=0;

s= 1e9; // Scalefactor 

k=0;

int t,dt;

p_dir @ t <: direction;

t += 6*us;

// Acc. phase  v = cumsum(a);

while(k <  microsteps/2  ){

  v += min(a[v] , a_max);

  v =  range(v , v_min , v_max);

  p_step <: LO @ t+ pulseWidth;

  dt = s / v;

  if( dt > USHRT_MAX)

    /* Wait dt/USHRT_MAX cycles...  */

  

  t+ =dt;

  p_step <: HI  @ t;

  k++;

}

//deAcc. phase 

while(k <  microsteps/2  ){

  v  -= min(a[v] , a_max);

  v =  range(v , v_min , v_max);

  p_step <: LO @ t+ pulseWidth;

  dt = s / v;

  if( dt > USHRT_MAX)

    /* Wait dt/USHRT_MAX cycles...  */

  

  t+ =dt;

  p_step <: HI  @ t;

  k++;

}

to save RAM usage for high velocity steppers we can do

v+ = a[v>>n] or v- = a[v>>n]; and scale a[v] during init.

The planner thread will send microsteps, vmax and amax to each stepper thread;

[Mikael Bohman]

Added support for 5-pin MOLEX connector for steppers so I can use shielded motor cable, to avoid USB problem.

[Mikael Bohman]

TBC!

Den fredag 4 augusti 2017 kl. 01:00:37 UTC+2 skrev Mikael Bohman:

[Mikael Bohman]

It's ALIVE ... at least the X-axis.

So far only G0 and homing implemented.

[Jason von Nieda]

Very exciting! Do you intend to post the code? I'd love to study it and learn more about XMOS.

Jason

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4c4c9b5e-84ed-4c32-ae21-5e4cdfe8a6e3%40googlegroups.com.

[Mikael Bohman]

As soon as the code has reached some maturity, I will put it on my git.

[Mikael Bohman]

I did a new CAD revision of the controller board this Easter.

• Output for X , Y0 , Y1 stepperdrivers, which are external 2DM860H and feed with 42V AC.
  

• Z, C0 , C1 are AMIS-30543 drivers soldered directly on the shield (24-30 V DC). With SPI control and with up to 128 steps of microstepping.
  

• 4 endstops for X, Y0 , Y1 , Z
  

• 2x4 MOSFET output with pwm support and with up to 3 different rails. Each bank can have 3 different voltage stage.*
  
• 1 half H-bridges (MOSFET)  for pump control.  Advanced PWM controll, generating softstart etc for the 12V pump. No need for different supplies.
  

• 2 vacuum sensors with 12 bit A/D over I2C; (0 - 100 kPa abs. p)
  
• One 12-bit A/D over SPI for load angle feedback for the Z axis stepper.
  
• Header for I2C and SPI, and 4 extra GPO pins.
  

• 3 constant current PWM capable LED drivers, with to 350 mA each.
• Extra ground connectors to connect the shield of all cables going in the dragchain to avoid EMI problem with the USB camera.

*With all MOSFETS & LED current being PWM controlled by, I only need one rail 24-30 V. All different voltages for solenoids etc are created with PWM @ 25kHz 2ns resolution.

The current to the Z, C0 , C1 steppers are dependent on the axis movement to lower the heating. 

 

I have working X,Y,Z interpolation and I'm currently working on nozzle awareness. The controller will know all places in the machine that is dangerous for the nozzle, and send an error to openPnP instead of crashing the nozzle :)

A move to Z=0 in the change nozzle region is replaced with a home Z by the controller. That way the Z axis will never slip when chaining nozzles.

  

[Mikael Bohman]

I also made this board, trying to replace the 3 external stepper drivers for X,Y0,Y1.

The motherboard is a Xilinx ZYNZ 7020 made by myirtech.com

The MOSFET will be cooled by the AL 40x20mm profile.

Instead of running simple frame by frame current control, I will try to use Delta-Sigma with noise-shaping to avoid aliasing tones in the frequency spectra < 20kHz. 

A common problem is non harmonic tones generated in the acoustic region for human hearing. 

Also, it will not run steps, instead it will run at a constant sampling rate.

The planner will thus be integrated with the controller, making it possible for the controller to retard the acceleration if the output voltage is reaching the rail voltages.

It will create sine-waves at 48 kHz instead of trying to interpolate a sine-wave from a step signal.

TBC!

[DAniel Dumitru]

Hi Mikael,

I have been looking to XMos for long.
Could you please tell us what SW are you running on that board?

Daniel

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ea8ee6f8-fa81-46a4-95ff-6a09b97043cf%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

---

This email has been checked for viruses by Avast antivirus software. www.avast.com

[Mikael Bohman]

https://github.com/lilltroll77/openPnp1v1

 

I started with the USB Virtual COM port example from XMOS. Works out of the box in Win10.

Then I just added feature after feature myself. I know almost nothing about the other GCode implementations. 

 

The stepper velocity is recalculated for each step. An easy task for XMOS to do.

The current github code does not include the a[v] lookup table for the steppers, but it is easy to add. 

I can almost make my machine jump of the table, spraying 0603 every there, so I do not need it before I can bolt my machine into the floor or something like that.
a[v] means that the acceleration/torque is depending in the current velocity, since the available tourque depends on the angular velocity of the stepper (and the rail voltage).

[Juha Kuusama]

Cool!

What step rates do you achieve?

[Mikael Bohman]

I'm currently using 2 uS minimum pulse time, because that is the AMIS maximum digital speed.
The XMOS timing analyser says that you can run the loop below 500nS, updating the acceleration on each step. 

The instruction that takes some time is the unsigned div, since it takes several instructions to complete.

2us equals 250ksteps / s , since we need one low state and one high state to create one step.

[DAniel Dumitru]

Mikael - just for curiosity how you will synchronize 3/4 independent motor movements ?
(not that wold be needed in this application)

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/17171d44-d096-402f-8d3f-cfffb0553c65%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mikael Bohman]

It is implemented for X,Y,Z and you might need it when changing nozzles.

First I calculate acceleration and velocity profiles for each axis in a master thread. Adjusting for the slowest axis if needed.

Concurrently each axis has it's own hardware thread that until now was sleeping if not several commands has been queued up.

Then the acceleration, max velocity and number of steps are sent to each thread over streaming channels.

The last channel transaction will also work as a thread synchronizer in this case,

When a stepper axis thread has finished it will send a control token back on the channel.

For M400 command, the master thread will read in the control tokens from each thread, and pause if not all tokens are yet available. 

That way both the beginning and the end is synchronized. 

The channel end has a 64 bit HW FIFO. A control token is 8 bits long, meaning that if you like, you can send up to 8 move commands for each axis before you need to fetch control tokens and synchronize the end of the movement.

A paused thread will give it's time-slot to other threads that are running. 

Each active thread executes 1 instruction during 2 ns, thereafter the next active thread is executed for 2 ns in a round robin fashion.

If you need even better sync, you can use the hardware synchronizers. That way, the master thread will fire up all the slaves concurrently.

The timing of the output ports is determined by the port timer, and not by the current instructions. All steppers threads are sharing the same port clock.

So even if you have a 2 ns lag between threads or much more, the output signal can be fully timecontrolled anyway, giving perfect sync for all steppers.

The ALU will send the port value and the port time to the port buffer, then just continue executing the calculations for the next step.
Each port will then handle the output independent of the ALU:

It should not be a problem for 3d printers etc, needing perfect interpolation between many axis.

[Mikael Bohman]

I have improved the XMOS code now. The master thread will not start the clock until all stepper threads are ready.

Each thread will fill up the port FIFO buffers, and then go to sleep. Thereafter the master will start the port clock.

A M400 command will end with that the master stops the port clock.

I suspect that I now have port synchronization down to ps. Only the different length of the physical clock tree in the chip + jitter.

I will check it with my oscilloscope later.

Den fredag 4 augusti 2017 kl. 01:00:37 UTC+2 skrev Mikael Bohman:

[Mikael Bohman]

Here I have first moved the head 10um in X and 10um in Y.

Then I press the P button in openPnP and capture this.

Measured at the input for the external stepper drivers.

The cable reflections, and difference in conductor length is a much worse problem than the timing error from XMOS.

[Paul Jones]

You should be able to fix the reflections by slowing the rising edges a bit, as they seem significantly faster than they need to be. Try using small (pf) capacitors on the outputs, or if the XMOS chip has configurable output rise times try a slower one.

 

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0f0568db-a66a-42cd-8d1f-aaa8d8d13132%40googlegroups.com.

[ma...@makr.zone]

Hi Mikael

First let me congratulate you on your cool project. Please don't get the following in a wrong way ;-)

Regarding your scope shot and your remarks: Either the time units (µs) are wrong or I am misunderstanding something...

A stepper motor driver usually uses a ~40kHz chopper to modulate the current into the coils. And it is only using 40kHz so humans don't hear it. It would be fine to use even coarser chopping If you weren't bothered by the "music". That's the first indication that anything below 1s/40kHz = 25µs is irrelevant.

The stepper coils have am inductance (L) in the order of mH so whatever change in voltage you apply to the coil is only veeery slowly changing the current in them. From the Wikipedia let's take:

v(t) = L*di(t)/dt

it follows

di(t) = v(t)*dt/L

So assume your 24V driver reverses the voltage (that's most extreme it can do) to your 2.4mH stepper and look what happens in 1µs:

di(1µs) = 24V*1µs/2.4mH

di(1µs) = 10mA

As motor power is to the square of the current, that's 1/100 x 1/100 = 1/10'000 of the power of say a 1A peak motor i.e. nothing.

For 10us its still only 1% power change (still "nothing", mechanically), for 33µs we get a mere 10% change. And remember that's only to one half of the sine wave, only a half-step. Add to that the intertia of the motor rotor and the whole axis moving that will work the motor like a generator, create back-emf and smooth things out a lot more.

So: your step signals being off by sub-microseconds is completely irrelevant.:-)

The only reason we need high step rates is because of the micro-stepping we want too. When the motor is coming to its target coordinate we want to nudge it to a specific sub-step position. So we need the high resolution. Consequently we need to have a high step rate at high motor velocities just to get the position information to the driver fast enough. Step/dir is just such a primitive way to tell the driver what to do. That's all.

The following shows a Trinamic TMC2660 driver going very slow (~400mm/min) on a standard NEMA17 setup (1V = 1A). Note the time scale at 1ms and the roughness of the chopper. That very smooth Trinamic quality internal 256 micro-stepping on an optimized SpreadCycle chopper. Expect worse with every other driver:

At the high speeds we want with PNP it is not relevant how jitter free the stepping occurs inside the micro-steps because the back EMF of the motor is dominating and shaping everything. Micro-stepping is completely irrelevant, if you were to send your micro-steps in packets (i.e. do a full step as fast as your driver can take pin toggling) you would not notice the difference or maybe even get an improvement as switching to full steps is actually recommended at high speeds.

In fact the driver is struggling to get the current into the motor coils at all and will only reach a fraction of your max current setting. A very crude shape will result (note the difference in the current sense voltage scale from 1V to 200mV):

You might also look at Figure 7 here:

https://www.trinamic.com/fileadmin/assets/Support/Appnotes/AN001-spreadCycle.pdf

Jitter inside the micro-stepping is only relevant for slow moving motors in applications other than PNP such as milling metal etc. And even there its only relevant in the dozens of µs (and then often just to reduce noise). Jitter in the multi-µs range might be a challenge for 8bit microcontrollers but not for any reasonable 32bit microcontroller with less than 6 axes.

 

I guess the multicore power of your system should rather be spent in the motion planning. That is done very crudely in the current implementations due to limitations of the single core.

Also if each core supports concurrent hardware SPI channels this could be veery interesting indeed. Modern drivers should be interfaced with real-time SPI to get the most out of them. You can then adjust current, micro-stepping, chopper settings etc. on the fly as you move. With some Trinamic drivers you could even do a kind of "closed loop" implementation, speeding up motors to the limit as reported back by the driver. As far as I understand that's not practical with single core MCUs.

-Mark

[Mikael Bohman]

Hi :)

Regarding the FPGA project:

The objective with all PWM techniques is to create frequencies below the modulation switching frequency. The frequencies above is just a side effect.

 

If no frequency components where created below 20 kHz, no substantial torque would be generated by the stepper.

For a 200 steps/rev stepper we need a 200 Hz sine wave component (and cosine wave) to make it rotate at 1 rev / s. If you use a squre wave, the sine wave component will be a part of it, (proven by the Fourier series).

 

A side effect with all pwm, is that unwanted frequencies will also be created below the switching frequency, at least for a subset of all possible modulations.

 

An example often used in audio, is to used Delta-Sigma modulation with noise-shaping + dither to force as much of that energy unwanted energy above 20 kHz as possible.

 

I’m 100% sure of that there always will be frequency components below 20 kHz as soon the stepper is enabled. You can always ask the Fourier transform for guidance in that matter.

 

Since, I have the equipment I will capture a Spectrogram of the stepper current later.

What I do not know, is how much unwanted energy below 20kHz that is present, but the spectrogram will tell.

I understand why you want to switch to full steps at high rev etc, but I see it from a non-linear control system perspective, and finds the ideá with stepping the steppers ... outdated.

Regarding the XMOS project:

I understand that sub us axis synchronisation is irrelevant, especially for openPnP, where not perfect interpolation between XYZ axis is needed.

From the beginning I did not care at all, but then I got problems with my old nozzle-changer, when I needed the nozzle to move in a straight line in XYZ space.

At least for me, it is of “academic interest”, if it can be proven that there never will be any synchronisation problems due to the software/hardware implementation. Then you can encapsulate that function and hide it away, to never need to think about it again, even if someone starts to use the code for something that is more time critical.

I have a lot of MIPS to use, so let’s throw DSP instructions on the problem and see how perfect it can be done with XMOS.

 

Right now, I’m working on a lookup table for square root calculations, to improve the accuracy of the interpolation between a movement in XYZ == motion planning.

The start syncronization is no good, it the movement is not in sync at the end.

[Mikael Bohman]

Or wait, a full "step" is a 90 deg phase shift!? We need 200 x 90 deg phase shift for one rev.

So we need a 50Hz (sin,cos) wave to make a 200 step/rev stepper rotate at  1 rev/s ??

Den fredag 4 augusti 2017 kl. 01:00:37 UTC+2 skrev Mikael Bohman:

[ma...@makr.zone]

The objective with all PWM techniques is to create frequencies below the modulation switching frequency. The frequencies above is just a side effect.

I might have misunderstood the setup. I was under the impression that you just generated step/dir signals and used external stepper drivers.

If you start to generate the chopper (full bridge gate) signals directly, then - WOW! - this becomes much more interesting and more time sensitive, I agree.

Doing so from your XMOS would be veeery cool indeed. But you'd need fast dedicated ADCs or digipots/DACs + comparators to measure / catch the coil current tresholds. Quite some advanced fast analogue electronics there....

Or wait, a full "step" is a 90 deg phase shift!? We need 200 x 90 deg phase shift for one rev.

So we need a 50Hz (sin,cos) wave to make a 200 step/rev stepper rotate at  1 rev/s ?

Yep, it took me some time to figure that one out too :-) 

It's also the reason that you always lose multiples of 4 full-steps and not just one, when your motor stalls.

It's also the reason that you can visually see it from the top camera when you go back to your homing fiducial:

20 tooth pulley x GT2 (2mm) / 200 full-steps/rev  x 4 = 0.8mm

Clearly visible. And that's why it is useful to be able to do that when you tune your motors... :)

_Mark

[Mikael Bohman]

The current FPGA solution has 6 H-bridges controlled by the FPGA. Both the current and voltage are sampled at 1 Ms/s.

I do not expect my current solution to be the final solution, but I need to start somewhere.

I might switch to XMOS instead, since it is easy to connect several chip together on different PCB's with CAT 6 cable & LVDS  at 200 Mbps full duplex.

 You can also make it galvanic isolated with only one Si8642 chip on the communication channel, instead of using an army of opto-isolators between the DSP and the MOSFETs.

One board would have the USB connector and the rest can be daisy-chained with CAT6.

XMOS would give a 2 ns resolution of the port timers. I'm running the same on the FPGA.

[Mikael Bohman]

Perfect S-curves with XMOS.

Some math later I have this example using 4:3 steps for X,Y with the goal to start and end at the same time, by calculationg the acceleration. It handles both odd and even number of steps.

Below: Zoom in of the last pulse.

[Mike Menci]

Hello!

Very Good! Keep on !! 
Mike

[Mikael Bohman]

Using prime ratios: 997 steps to 983 steps for X,Y axis

The last pulse for X,Y

Can I improve it? ... hmmm

[ma...@makr.zone]

I missed the FPGA part (impressive!) but do you still use step/dir between the XMOS and the FPGA? I think not, because you also said:

The planner will thus be integrated with the controller, making it possible for the controller to retard the acceleration if the output voltage is reaching the rail voltages.

It will create sine-waves at 48 kHz instead of trying to interpolate a sine-wave from a step signal.

I still don't get it, it seems :-( 

_Mark

[Mikael Bohman]

Ok, at the moment I use XMOS instead of smoothieboard. My XMOS card has 3 outputs for external stepper drivers.

At the moment I use 3 DM860 external drivers for X, Y0,Y1. They are DSP based with a TI fixed point DSP.

I hope I can do it better than that myself, so the plan is to replace the 3 external drivers with the FPGA based solution. The FPGA card also has USB, so with help of sub drivers in openPNP, I will use 2 USB cards in total XMOS + FPGA.

To sync all axis, I can use one sync wire between the XMOS card and the FPGA card. When all planning calculations is finished, all axis can start moving.

That will also give me 3 free stepper driver outputs on the XMOS card for feeders or other inventions.

[Mikael Bohman]

Next version of the code.

 

Timing accurucy in the calculations, updated for each step is now down to 0.47 as (attosecond ==one quintillionth of a second) to avoid accumulative errors in the calculations.

Using a non trival prime numbers of steps: 299993 steps for X-axis and 99991 steps for the Y-axis, reaching a maximum velocity of 500 k steps/s in the middle. (Which is above the limit of all stepper-drivers I know of.)

MATLAB simulation:

Measurement:

First pulse:

In the middle:

Last pulse:

The total error in the end is 6ns. 

I might be able to live with that timing error, but it is possible to get down to [0 2ns].

The planner calculates the total number of steps, maximum velocity with 64 bits of fixed point precision, and acceleration as floating point with a 32 bits mantissa.

All other calculations is done in real-time in each stepper thread. 500kHz is no problem.

 

[Mikael Bohman]

Is jerk limitation important for the machine? It would limit HF components of the force generated by the stepper, instead of generating a Step_function of torque.