CSMIO/IP-M and slave axis functionality

Following a brief mention by Jazz in a different thread, I had a look at the CS-Labs website where they say that the CSMIO/IP-M now has slave axis functionality. They also say that it does not include full gantry geometry correction (which the CSMIO/IP-S does do, at about 2.5x the price!). I have mailed them to see if there is any more information available, but this looks like an important enough development that it deserves a thread of its own.

My new machine has reached the point where I am thinking about an external motion control card, as well as alternating on a more-or-less daily basis about whether to go single motor/twin belts or two motors for X. Even if I go single-motor now, I don't want to get a motion controller that stops me going 2-motor at a later date if I feel it necessary. If I were happy with single motor then the IP-M would be my choice, but if it is single-motor only, I might look at alternatives (ESS maybe? Does that do slave axis homing properly now? Pure Logic PLCM-something?). This new development might solve the problem - IP-M can do both, has 24V operation for good noise immunity, decent opto-isolation and other nice features including spindle speed control on the same board. I'm guessing that there are others out there in a similar position, or at least thinking about upgrading to an external motion controller.

I've had a look at the IP-S manual to try to second-guess what the lack of gantry geometry correction might mean. As I understand it, the IP-S can do a calibration run where it homes both axes, measures the offset between home switches, and builds this into the configuration parameters. The user can then tweak the offset value to fine-tune for squareness, etc. Maybe the IP-M will lack this calibration capability, which means manual adjustment of home switches? Don't know - but would like to! It looks as if the IP-M manual available online hasn't been updated with this new functionality yet.

I shall post any more information received from CS directly, but would like to hear any other comments or information or especially experience of playing with it in this mode!

Quote:

---

Originally Posted by Neale

I might look at alternatives (ESS maybe? Does that do slave axis homing properly now?

---

Yes, this version of the driver, ESS_v10r2d1d.zip , has been working fine for ages now, the previous version used to give me problems. I'm using two motors X and A as slave but I only use one homing switch on the X side, I might fit two at some stage but as yet one works fine.

Eddy - how do you cope with the possibility that the steppers lose position when you switch off, so that possibly the gantry goes slightly out of square each time you switch on? Or do you square it manually somehow from time to time? I thought that that was the advantage of two homing switches. Or does practice trump theory, as is often found?

- Brian

I think you need two homing switches. I use the Pure Logic PLCM-something from Zapp and it home very well with the two switches but I have to set it up by adjusting one of the switches to get the gantry squaring correct, after that it sorts its self out at every home position. ..Clive

Quote:

---

Originally Posted by Neale

Following a brief mention by Jazz in a different thread, I had a look at the CS-Labs website where they say that the CSMIO/IP-M now has slave axis functionality. They also say that it does not include full gantry geometry correction (which the CSMIO/IP-S does do, at about 2.5x the price!).

---

It would be pretty trivial to program a PIC/Arduino/pick-your-favourite-microcontroller to square the gantry and let you enter offset numbers to save very fine adjustment of limit switches, so I wouldn't pay more than a few £ more for a motion controller with this feature.

Quote:

---

Originally Posted by Jonathan

It would be pretty trivial to program a PIC/Arduino/pick-your-favourite-microcontroller to square the gantry and let you enter offset numbers to save very fine adjustment of limit switches, so I wouldn't pay more than a few £ more for a motion controller with this feature.

---

Well how about sharing the code with us mere mortals:devilish: ..Clive

I would agree that programming an Arduino (just because I know that one) would be pretty easy if all I wanted to do was measure offset between a couple of not-quite-accurate home switches. I haven't thought through the details, but I suspect that that is only simplifying what is not a particularly difficult task anyway. Measuring gantry squareness seems like the biggest issue rather than tweaking switch positions and that's common to all setups. However, I'm not sure that I could use those values in any of the usual solutions, so the straight hardware-based "tweak switch until dual-homing leaves the gantry square" solution seems inevitable.

I currently use LinuxCNC and I've had a look at that from the point of view of dual-motor homing and operation. It seems somewhat incredible that with all its users, there still seems to be no official solution to this particular problem. From what I see and read, it seems to be bound up in the internal representation of a machine which makes a generalised solution very difficult, although I did wonder if a custom job for my particular machine geometry might not be possible. Still, at the time, the latency of my garage/CNC PC was such that an external motion controller looked like a good option for my Mk2 router, despite needing a move to Mach3. Then the motherboard went pop a week or so back, and the cheap replacement is performing much better, so I'm just confused.

Stay with LinuxCNC? That forces me to single-motor/twin belts, but I probably now have sufficiently low latency figures that I can get reasonable performance. Dual-motor? That means Mach3 (or one of the dedicated hardware/software combinations like PlanetCNC). What I don't want to do is invest in kit that limits later options, at least not unreasonably, and the CS Labs boxes seem to have a decent reputation from the point of view of reliability, etc. Hence the interest in this new IP-M development.

So Neale what you do normally when you start your machine? Bump the gantry to some gantry hard stops as a dedicated Linux user? :hysterical:

Its seems incredible, but its the same with Mach3. I am sure half of the motion control plugins are not capable of it or are very obscure. Mostly cause people who write them have mills and dont have a way to try it or think that all people in the world use servos with absolute encoders.

The way i see it it is a must for steppers.

No, my current machine doesn't even have home switches, so I'm not exactly pushing the limits of LinuxCNC!
I know that LinuxCNC does not support master/slave motors; thinking about it, I've never looked at whether or not Mach3 supports this natively (via parallel port, no motion controller). Is this a capability that comes from a motion controller, not Mach3?

So what you need is someone with a IP-M to test this for you.!!. . . . . Ermmm

Well It just so happens I know a guy, who knows a guy, who's got a friend who knows a Gal, who's brothers got a couple sitting around doing nothing. . :hysterical:

Ok I'll try and test how it works for you. Not got a dual axis machine in a build state to test just at minute but I'm sure I can Rig up something to test how the motors sync and home on the bench.!. . . . Leave it with me a few days(weeks,months,years!!)

I've Nagged CSlabs brains out for this option since I started using these and it was mentioned that it couldn't be done due to hardware restrictions so I'm intrigued my self.?
I suspect it will work just like any other mach3 motion controller in that each motor just hits the switch and backs off. The IP-S works the same with steppers, thou it can HOME using the Index signal of servo encoders or if shaft encoders are fitted, where the IP-M can't do this I believe.
The IP-S also has an option to measure the trip error between switches and correct. This works very well because I tested it the other week using dial gauges and setting a large error. It brought it back perfectly to within 1000's/mm.

It also the option to measure and Not correct the error just display error in the plugin.
Know to me the this is useful but not like your probably thinking.? It's useful to me for setting the switches accurately as it works out the error between them so I could set the gantry square without twisting the gantry to make square, Which you don't want or need too ! . . Now I'm sure Golden Balls could easily do all this with the Pic up is arse.!! . . But I'm into using machines which means I want a quick way to set the machine accurately and forget not thrashing the few remaining bits of gray matter or pulling my Togger over capabilty's of Pic.!

I'll most a Vid if I get time.

Quote:

---

Originally Posted by Neale

Measuring gantry squareness seems like the biggest issue rather than tweaking switch positions and that's common to all setups. However, I'm not sure that I could use those values in any of the usual solutions, so the straight hardware-based "tweak switch until dual-homing leaves the gantry square" solution seems inevitable.

---

You can measure the squareness of the gantry as follows:

1. Use the machine to drill 4 holes at the corners of a square (or rectangle), e.g at (x,y)=(0,0);(0,100),(100,100),(100,0).
2. Measure the diagonals of the square/rectangle accurately.
3. If the diagonals aren't equal, your machine isn't square, so either draw the actual dimensions in a CAD program to find how far from perpendicular your axes are, or just calculate it.
4. Offset, and try again... repeat until you deem it square enough.

I find that drilling 4mm holes in a piece of MDF, then pushing 4mm drills into the holes and measuring the center distance with a digital caliper works well and is repeatable. Since I don't have limit switches (a case of a few years ago 'oh it works, time to use the machine now not carry on with wiring'), I just make marks on each rotating nut which align with a mark on the housing when the gantry is square. Then I check that the marks are aligned when I switch the machine on - I can see if the marks are out by about 1/4 of a step, so it's accurate. The machine stays square when switched off unless accidentally knocked...which is fair enough really. If I crash it then I do the above squaring procedure and I do it every 6 months or so just to make sure.

Anyway...

The principle with Arduino's is they provide you with an extensive library of functions that make it very easy to code things as it adds an abstraction layer between the user and setting the microcontroller registers. For that reason I tend to dislike Arduino's because the built in functions limit what you can do to fairly simple stuff, so you end up having to program the microcontroller directly and therefore might as well do that from the start. However in this instance I think it's simple enough for the Arduino language to do what we need. Also, you don't need a programmer (Pickit or whatever) as they program via USB.

The way I envision is for the Arduino to send the step and direction signals to the two X motors and read the limit switch signals, so it takes control of the machine to make it square, then leave the X axis in the home position. The normal machine controller can then take over. We could add potentiometers to set the feedrate and acceleration for homing, or just leave it in software. One extra input for e-stop I guess...

So I think it's worth me acquiring an Arduino and trying it, then I'll post the code and wiring diagram here. Not sure how long it'll be until I have chance to do it, but if someone who already has home switches is willing I'll happily help them wire it up and program it over Skype. One of these should suffice. Jazz could also use it for this.

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

To me the goal is to use the machine and it be accurate. If I have to start programming Adhoc micro processors to do what is in affect a simple operation then i'm not interested and neither should I have to be.! . . . . . If your prepared go to the bother of programing hardware then why bother buying any controller or drives and just build your own.??? . . . Why not because it aint worth the trouble trying to re-invent the wheel.

Most people with steppers don't buy the IP-S because it can do slaved motors or calculate switch error (they are daft if they do or have too much money.!) They buy it because it's quality unit which is very powerful, versatile which offers industry standard I/O with an easy upgrade path to using high count servo's and getting the full potential from them at a later date if required.
Yes other controllers like the ESS can do this but they don't have the quality or smoothness like the Cslabs products and not until you have experienced both or several manufactures controllers do you know this.! . . . . I've yet to use anything in the same price bracket that comes near the Cslabs stuff.!! . . . If I had I'd be shouting about it.!!

Jazz, it would be MUCH appreciated if you could spare the time and do a test for us on the IP-M slaving!

Quote:

---

Originally Posted by Jonathan

... 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.

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.

Quote:

---

Originally Posted by Neale

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.

Quote:

---

Originally Posted by Irving

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.

Quote:

---

Originally Posted by Neale

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.

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.

Quote:

---

Originally Posted by Neale

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.

http://youtu.be/mNZ4wOTg8jE

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.

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.

Quote:

---

Originally Posted by silyavski

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.!!

Quote:

---

Originally Posted by silyavski

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". . :hysterical:
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.!!

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

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

Jasko - thanks for that. I have tested this with my own machine and it works fine. Because all my home switches are connected to separate inputs on the CSMIO, I home Z, then X/Y/A simultaneously. To do this, my button script is:

RefCombination(4)
RefCombination(11)

Note - I use X+A as my dual axis. However, this script would work with Y+A as well. I home Z first to ensure that the spindle is at maximum height to avoid hitting anything while the other axes are homing.