CSMIO/IP-M and slave axis functionality

[Neale]

I know that these kinds of threads drift around and about the topic sometimes, but for me it often helps to air issues and aspects that I haven't really thought about. So...

The name of the game is to get the gantry square, and keep it there while the machine is working. To do this, we need a way to measure gantry squareness, at least as a one-off operation (and assuming that we don't crash it into anything). Jonathan's method sounds simple although I'm sure that other people have their own favourite techniques. OK, so we have set the gantry square, maybe by manually turning the leadscrews. Now we need to be able to rehome to that position. Jonathan's manual method, again, sounds simple and appeals to an engineering mind - why do it a complicated way when an easy and cheap way exists? I'm sure that marking a pulley for a rotating screw system would work equally well. But if we have home switches, then it sounds nice if we could just press a button and get the homing done automatically. That means setting the gantry square, and either moving the home switches or their actuating targets so that both switches fire at once, or use some method to measure the home switch offset and calibrate that out in the software/config parameters. The separate "homing and measuring by Arduino" could do that - although it means swapping driver inputs or finding some other way to combine drive signals? - or use something like the IP-S which does it in firmware. I suspect that this is the bit that is missing from the IP-M - it can drive two motors simultaneously to home master and slave, detecting separate home switch activations, etc, but cannot do the measuring or do the offset in firmware. So, it will need mechanical home switch adjustment. Don't know how difficult this is in practice?

Then, we come down to operation. That means pulsing two drivers in synchronism. You shouldn't just wire two controllers in parallel and drive them from the same BOB output; in theory it might work but I can see that if the driver inputs are opto-isolated, there could be issues. So, ideally, you need a way to generate synchronised drive pulses on master and slave axes. That could be via Mach3 (can it do that internally?) or LinuxCNC (same question), or something like the cheap BOB I use which can copy one input axis into two output axes, or a motion controller that knows what to do. That's something that the IP-M could not do in the past but I guess can now do. However, unless we have a system (which probably means external motion controller) that can automate dual-motor homing, we must use a manual homing mechanism as described by Jonathan - which doesn't sound like too big a deal.

Anyway, I don't think that I've said anything new here, but thinking out loud does help clarify my own thoughts! Probably bores the pants off the rest of the world, though...

Jazz - if you get a chance to test the IP-M, I'd be very interested in the results, if only to find out what functionality is in there, but I realise that you have plenty of other things on the go and I don't need to make a decision for a while anyway.

Jonathan - I tend to prefer thinking in Arduino terms only because I have one in my 3D printer and started there. I've done a bit of work with them since and found out that it's pretty easy to burn firmware into them as needed for dedicated jobs which has been useful, but I've no particular axe to grind one way or the other.

- Brian

[irving2008]

... Jazz could also use it for this.

Gosh, I'd forgotten all about that thread...

It's amazing how cheap Arduino's have become, but I'm starting to like them over a raw PIC just for the ease of programming and deploying them - writing a sketch is very quick in the IDE on the PC then testing it is arguably much easier, IMHO, than doing the same with a PIC and the PICKit or writing some code on a Raspberry Pi.