CSMIO/IP-M and slave axis functionality

[Neale]

Just had a reply from CS Labs:

"CSMIO/IP-S controller thanks to the slave axis function uses two limit switches placed on both sides of a gantry.

With the an advanced algorithm it homes both motors simultaneously and after that it performs gantry geometry correction.



CSMIO/IP-M controller uses one homing switch mounted on one side of a gantry.

Slave axis function in CSMIO/IP-M controller works the same like you would connect two drives to one step/dir output. "

So, no decent homing/squaring function on the dual-motor axis. It just copies master step/dir signals to a second slave output. A bit disappointing. I had hoped that they had copied at least some of the IP-S firmware to the IP-M but apparently not. Still, we've already discussed "manual" homing techniques, so maybe it's still worth going IP-M for build quality/performance, etc.

[Jonathan]

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),

In LinuxCNC you can just assign two step pins to the same axis and the same for the direction pins. If you are just sending the signal to each, that's a bit of a waste of pins - you might as well connect the same pins to both drivers inputs and if the impedance of the breakout board is too high to drive them properly, just buffer it with your favorite logic gate / transistor. In fact you can kill two birds with one stone here - we need the Arduino board to also be connected to the driver inputs, so the easiest way to do that is to for example put an OR gate in so either signal can reach the drivers. Just be safe I'd block the signal from the parallel port with an AND/NAND gate to ensure the computer can't accidentally move the machine whilst the Arduino is homing it.

Once the Arduino has set the gantry square, you can safely send the same signals to both drivers and leave the Arduino idle, or even use it for some sort of fault protection to monitor both motors and detect loss of synchronization.

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

I tend to agree - they're a good 'stepping-stone', until you meet the limits imposed by their IDE, to programming them 'properly' in C/ASM. On a vaguely related topic, have you spotted this one? It's a bit good.

With the an advanced algorithm it homes both motors simultaneously and after that it performs gantry geometry correction.

Advanced, really! The sad thing is that this isn't remotely advanced, so should really be included either way...

It's occurred to me that one could quite easily program LinuxCNC to set the gantry square by making a profile that defines the X axes motors as separate axes. You then run some G-code (or something more sophisticated, who cares) to set the gantry square, then load the normal profile to run the machine.

[mitchejc]

Well Neale, that's not all bad news and I'm seriously considering the IP-M for my build. Like you say its probably worth it to have a reliable controller even if the x squaring would be manual on a slave setup.

[JAZZCNC]

Slave axis function in CSMIO/IP-M controller works the same like you would connect two drives to one step/dir output. "

So, no decent homing/squaring function on the dual-motor axis. It just copies master step/dir signals to a second slave output. A bit disappointing. I had hoped that they had copied at least some of the IP-S firmware to the IP-M but apparently not. Still, we've already discussed "manual" homing techniques, so maybe it's still worth going IP-M for build quality/performance, etc.

Yes correct but don't be too diappointed because the slaving works well, as you'll see in the video and remember this is just a Beta version of the plug-in.
I mention my view on this this in the video so I won't repeat my self.! . . . . Watch the video.

Edit: Also don't be put off by Nah sayers who have no experience of using these controllers.! . . . . They wouldn't be so Negative if they'd used one. This exactly why I try different controllers or products and make my own mind up rather than listening to others because there are too many people too quick to knock or recommend products they've never experienced.

[mitchejc]

Thanks Jazz its great to actually see this controller in action. Just made up my mind, I want one of these IP-M's for my machine.

[Boyan Silyavski]

Dean, Thanks for the video. Well what can i say, they move super smooothly. I hope they soon understand the right way to do it for the homing. Cause i dont see whats the f***g problem, that means they shortsightedly want to push their more expensive product by not allowing us this feature.

[JAZZCNC]

Dean, Thanks for the video. Well what can i say, they move super smooothly.

Yes very smooth and thats with drives straight from the box meaning I hadn't even tuned the motors to the drives which makes a big difference to motor smoothness.!!

I hope they soon understand the right way to do it for the homing. Cause i dont see whats the f***g problem, that means they shortsightedly want to push their more expensive product by not allowing us this feature.

I understand what your saying because I thought similair at first but when you look at it logicly I don't think thats the case because the IP-M and IP-S & A are very different animals. To me the IP-M is clearly aimed at the stepper world because it's frequency just isn't high enough for the Servo world. Where as the IP-S & A are designed for just that purpose and thrive at running servo's and high count encoders.

Thou the IP-S runs steppers very very nicely Very few will buy the IP-S for steppers due to it's high cost and Cslabs know this.!

Now where I feel the problem lies is that Cslabs are clearly Servo biased guys, the manual clearly shows this by the fact they put steppers down. Also if you look on there web site they don't sell or make a single thing that's stepper related and that's because they are secret "STEPPER HATERS". .
They also want to sell there servo own drives and servo motors.!!

Now I think they are realising that there may be some value to us pauper stepper muppets and probably due to others and the likes of me pestering them for slaving etc they have started to sit up an take notice a little.? . . . Probably not the case but I hope so.!!

Also believe me they certainly know how to make homing work because the IP-S is the best dual axis homing I've ever used bar none, works like the ESS could only dream to do.!! Infact the single axis homing is probably the best I've used, it's so smooth and reliable it never misses a beat and without any false triggers yet very sensitive to switch/input under normal working conditions. (Say this because Charlie did have an issue but was special case and not Controller related.! . . .infact the issue would probably have fried lesser controllers I/O.!!)

So what I'm saying is don't be so quick to pull them down just yet and give them a chance as they are good guys to deal with and certainly know how to make excellent product.! . . . They just need encouraging to look more towards the Stepper world as well and not be so biased towards servo's.!!

[Ger21]

Nice review. Now I need to raise some money for an IP-S.

[Jasko]

Hi guys
maybe too late but i just face this slave homing problem with ipm

I find simple and free solution

in cs plugin config i turn off Y (or X depend of your machine ) slave axes is A ( to none )

than Mach do homing and squering same way like smooth stepper do
DoButton( 24 )
DoButton( 23 )
DoButton( 22 )
DoButton( 25 )

after this i turn on Y slave A in cs plugin and machine work perfectly
its just few click in the beggining
hope its helpful

Jasko