Joe's 1000x600x200 steel and aluminium router started

Quote:

---

Originally Posted by Doddy

Interested to see how this goes. Glad to hear you're bit-banging, though as the 328 is inline with the axis pulses to the stepper drivers it has to keep up at all time (not just homing) and I'd be curious if you can hold the signalling whilst I2Cing the display - interesting challenge.

I did realise after writing that the optos were for homing switches/reflection into the DDCS, so, yeah, will be fine - I'll withdraw that.

---

Hi Doddy,

So it turns out if you ditch the standard I2C/TWI wire.h library and display driver, crack open the 328p datasheet, write your own crude framebuffer and I2C non-bocking state machine that operates directly on the TWI registers you can tick the state machine at a 2-3us per tick penalty. Will put it on the scope and see if this is sufficient.

Main loop becomes:
1. Mirror stepper/home signals with squaring logic.
2. Update framebuffer if needed (using a 5x7 font this is 5 memory reads/writes per character)
3. Tick I2C state machine.

I could remove the framebuffer to make it a bit faster if required, this will effectively amortise the font copy part at one byte/I2C tick.

Cheers, Joe

Quote:

---

Originally Posted by devmonkey

Hi Doddy,
write your own crude framebuffer and I2C non-bocking state machine

---

"Crude"?, I prefer to think of this as "fit-for-purpose".

You know as well as I do the 328 is just one of a thousand different micro controllers that pollute the oceans and the Arduinio packaging is just a convenient way of throwing that chip into an accessible form for stupidly low cost - makes them a sensible solution for even the most simple of problems. There's no reason to use the Arduino libraries unless you're concerned about cross-platform compatibility or speed/ease of development (sacrificing code base, efficiency and real-time performance). I think you'd agree programming at the register level (I gave up at the instruction level many decades ago - I prefer to have a compiler at least) adds a level of complexity and care, but if that floats-your-boat (and it does, me) then hack away to your hearts content. At least you can be confident that you know exactly that the uC is behaving exactly as you want it to.

So I've just scoped the DDCS. An axis setup as per my machine, 1610 screw, 16x ustepping -> 320 steps/mm, max speed 10000mm/min.

As expected step frequency is ~53kHz, half period of 9.375us. Nyquist/Shannon tell us that this needs to be sampled at a minimum of 2f, i.e. 106kHz for perfect reconstruction. Puts an upper bound on my mirror code latency of ~9us, so to be safe say 5us. This is 80 cpu cycles, will it fit?? Should do, got to wire it in and test.

DDCS defaults set dir 7000ns (7us) ahead of step therefore code running at 5us will always see this. EM806 only requires 2.5us but configuring DDCS to deliver this will risk breaking the contract woth EM806.

Interrupt on change of state? Your time-sensitive processing is in the discrete control and not the I2C if you're using the TWI registers.

Quote:

---

Originally Posted by Doddy

Interrupt on change of state? Your time-sensitive processing is in the discrete control and not the I2C if you're using the TWI registers.

---

Yes it is possible you can register for toggle interrupts on any of the IO pins, trouble is my code is written in arduino/cpp at the moment, this means there is a stack to park so there is some overhead from servicing the interrupt. If the current polling approach takes too long will have a look.

So here is a baseline, the basic axis mirroring with auto squaring, but without I2C. Lag is 600ns after a lot of messing about I just stuck the logic in a lookup table and deleted all my code ;-) Yellow trace is step output from DDCS running at 10000mm/min, blue trace is the arduino step output, lag is shown in 'dt' bottom right.

Attachment 28337

You're not going to get better than that!

Quote:

---

Originally Posted by devmonkey

after a lot of messing about I just stuck the logic in a lookup table and deleted all my code ;-)

---

Hahaha love it. Sometimes 'ugly' solutions are just the best.

My dual motor homing / squaring board is now working with the DDCS. Video clip below. DDCS was told to 'home' the X axis:

1. Each motor stops when its respective home switch is activated,
2. Once both home switches are activated the board signals home to the DDCS,
3. DDCS now backs X away from home searching for switch release,
4. If one motor's home releases before the other this motor is stopped until both home switches are released,
5. Once both home switches are released the board clears home back the the DDCS and DDCS zero's X co-ordinate,
6. DDC now moves X a pre-configured distance away from home.

This logic only activates when a home switch is hit and the machine is travelling towards home. If travelling away from home either switch hit signals the DDCS (i.e. it behaves as a limit switch).

The only downside of this is that in normal operation driving the machine past home in the X- direction requires both switches to activate before limit- is signalled. This is not a problem unless one of the switches has fallen off.

Attachment 28364https://youtu.be/dyFAdsQIpxA

Call me stupid, but what exactly do you adjust to make the gantry square once the whole sequence has finished? What is the purpose of step 4? Do you have separate cotrol of the two X distances in 6?