Joe's 1000x600x200 steel and aluminium router started

[devmonkey]

Ok your Stupid. . . .But so am I because I'm not seeing it either.?

To me it's just homing each axis separately, waiting until both inputs go high and backing off until both go low then moving both to a set distance.! It's not doing any individual axis correction and as the switches don't move it's not corrected anything.? Yes, you can square the gantry by offsetting switches using this method, which is how mach3 etc do it but so can any homing system really.!

If you want a true squaring system then it needs to drive each motor separately and adjust to a set distance. For instance, the CSlabs squaring system gives you options to measure the offset between the switch triggers and gives you the option to apply a correction to a set distance or let the system do it automatically. In which case it drives both motors until the first switch goes high then backs both off until it goes low, then it drives the opposite motor until switch goes high measures the difference and moves that axis only the measured difference. It's strange to watch as it does a little dance and the gantry is then aligned to the first switch.
If you want to apply an extra offset to twist either side then you can set a +/- distance for either side which it will apply after homing. It then backs both off a set distance if required.

Hi Jazz,

When you say any homing system can do this, the DDCS cannot as you proved yourself, infact no system can unless it is aware there are two motors on a single axis, i.e it has axis slaving, my board allows me to use the DDCS with two motors to square the gantry.

I also have the correction offset logic so you don't have to manually move the switches but currently no way to update these offsets without reloading the arduino as I haven't coded it yet. So in this test they were hard coded to zero, I thought this was the simplest way to explain how it works...LOL

Cheers, Joe

[JAZZCNC]

Hi Jazz,

When you say any homing system can do this, the DDCS cannot as you proved yourself, infact no system can unless it is aware there are two motors on a single axis, i.e it has axis slaving, my board allows me to use the DDCS with two motors to square the gantry.

Well I'm not sure how I have proved this my self.? but yes I agree if the system isn't designed to slave motors independently then it can't, but most systems like Mach3 or Linux CNC that use slaved motors independently can which is more what I was meaning. Your system appeared to just be doing what they do, but they don't Auto square the gantry to a set amount, they just move to switches that you set to square the gantry. (actually, I think Linux CNC can now.!).

Anyway good job all the same, I wasn't knocking your efforts just didn't see any auto squaring(offsetting) going on only hitting switches.!

[devmonkey]

Well I'm not sure how I have proved this my self.? but yes I agree if the system isn't designed to slave motors independently then it can't, but most systems like Mach3 or Linux CNC that use slaved motors independently can which is more what I was meaning. Your system appeared to just be doing what they do, but they don't Auto square the gantry to a set amount, they just move to switches that you set to square the gantry. (actually, I think Linux CNC can now.!).

Anyway good job all the same, I wasn't knocking your efforts just didn't see any auto squaring(offsetting) going on only hitting switches.!

I'm attempting to use the standalone DDCS controller for this machine Jazz rather than a PC. Before making this custom board I read Boyan's thread on these controllers here:
http://www.mycncuk.com/threads/10187...ion-controller

I was just quoting your posts in that thread where you tested one of these controllers and proved that it was not possible to slave motors and this obviously being a problem for machines with >1 motors per axis. Here you go:
http://www.mycncuk.com/threads/10187...5579#post85579

Maybe your miss understanding what was meant.? It was me who said doesn't work and I'm talking about Slaved axis. As in two motor/drives on separate outputs working as one axis.
That controller is exactly the same one I have and it DOESNT allow slaved motors. This video is just showing it working as 3 + 1 which the controller will do no problem. The fact they have twin screws means they are using dodgy practise of using one output to control two drives or even worse one drive to control two motors.?

IT DOESNT SLAVE TRUST ME.!!!!

I'm using the 4-axis version with much newer firmware but it still doesn't support slaving, hence the creation of this board to add the capability without the operator or the controller needing to know it is there, it just works passively in the background when required. The 4th axis is obviously then still available to use as a 4th axis as well.

For me the most important function is (re)squaring the gantry before every job, I think you are more concerned with setting up the initial squareness without moving targets. To be clear none of the methods implemented in any of the controllers perform auto squaring they all require some square reference setup on the machine to search for, whether that reference is the actual switch actuation point or some other position offset from it. Just like none of them support auto tramming or auto planaring (new word).

[Kitwn]

Ok your Stupid. . . .But so am I because I'm not seeing it either.?

Actually that should be "Ok you're Stupid' but the grammar police will let you off just this once

What confused me was the homing being set by the release of the switch. I only speak LinuxCNC which sets the homing on the (second) activation of the switch after the gantry has backed off and run in again slowly. An upgrade to version 2.8 includes the ability to have two separately controlled motors with their own switches to square the gantry. Then it runs off the switches by a set distance which can be slightly different for the two sides to fine-tune the squaring.

Yes, that is the whole point of this board I made, it enables the use of a single axis controller output and single home input to safely drive and also correctly home/resquare a dual motor axis with dual home switches. The controller executes its normal procedures without any knowledge that there are two motors and two switches.

That's basically what my board was designed to do but I opted to create all-new step pulses while the controller believed the machine was stationary. It also acted as the splitter for sending the pulses from one output axis of LinuxCNC to two motor drivers during normal operation. 'Great minds', eh?

[devmonkey]

That's basically what my board was designed to do but I opted to create all-new step pulses while the controller believed the machine was stationary. It also acted as the splitter for sending the pulses from one output axis of LinuxCNC to two motor drivers during normal operation. 'Great minds', eh?

Great minds! I just wanted the controller to stay in control at all times so I figured this approach was simpler and possibly a bit safer and it squares the axis as part of the controllers normal homing process. Not sure on the pros/cons of detection on approach vs retraction so long as it is done super slow I don't think it matters, may make more of a difference with mechanical switches.

I did notice a problem with my board yesterday, it was generating a spurious step every few seconds and you could hear them as faint ticks on the stepper whilst it was running. This was due to common mode noise on the step differential line, and is because I didn't bother to put a differential line receiver on the input lines, rather both the +ve and -ve signal are referenced to GND on the arduino. It was fixed by debouncing the inputs over 1 cpu cycle 62.5ns, i.e. reading them twice. However I think I will make a new board in a few days that properly terminates the differential signals, works well enough as it is to to get the machine working now. Any thoughts on the pros/cons of using a opto to terminate the differential signal like the stepper drivers do vs a proper line receiver?

The next step is work out how to bury these proximity sensors in the machine, the Z will be a bit tight and I may need to source a much smaller switch.

[Scustom]

Nice work devmonkey!!
Really interesting build!

[devmonkey]

So if you still have 4th axis spare then you must be controlling 2 drives with 1 output.?

Yes, that is the whole point of this board I made, it enables the use of a single axis controller output and single home input to safely drive and also correctly home/resquare a dual motor axis with dual home switches. The controller executes its normal procedures without any knowledge that there are two motors and two switches.

[Kitwn]

Not sure on the debouncing bit. Sounds like you have short duration spikes of noise but would need an o'scope to check. Some sort of filtering, ferrite beads or capacitors for example might sort it out but I haven't the experience with line receivers to advise you.

We've discussed opto-couplers at length in the past (wasn't Doddy involved?) and I have been experimenting with a Long Bendy Optical Coupler (LBOC) recently but that will be for another thread.

Kit

[Doddy]

Someone mention Optos? Great for killing line noise, but in this case my usual mantra of propagation delay through the Opto applies (but only because I've been bitten by Optos in the past). Arguable you should use a reverse-connected diode to avoid reverse-biasing the LED in the opto.

If you have noise on the line you really need to deal with it electrically, rather than through software, particularly with a finely crafted LUT solution as you have (I'm not taking the piss - it's a good solution here, mimicking one solution used by FPGAs for logic representation.... I'll be honest, when you first mentioned this project I was thinking it'd be a brilliant first-project for anyone looking to get into FPGAs, a Cyclone IV board will go cheap at around £20... but that sends the chat into a completely different direction and isn't really for this site) - in that case you could have easily configure for differential inputs. Anyway, as-it-is, I suppose my own view is clear from driving the spindle-encoder on the lathe - I use the MAX487 chips, on tuppeth-ha'peny Arduino RS485 interface boards to provide 120R differential drive/sinks as my weapon of choice.

[devmonkey]

Hi Doddy,

Yeh an FPGA would be an excellent choice although I don't have any non-BGA parts here and didn't want send out for 4 layer board to be made. Lattice have some TQFP parts that could be used but I haven't got any. I have some 485 line drivers though left over from running DMX lighting throughout my house, thanks for reminding me!

On the noise issue, it is being caused by the 328p sampling the differential pair wrt ground without removing the common mode noise (which will always be there). If I'm right it would be completely eliminated by properly terminating the pair with a line receiver.

The LUT does work nicely, I use an 8 bit address space at the moment, 6 input bits and 2 bits of state. I moved all my code into a loop that executes at startup, this iterates through the address space and writes the 8 bit output [2 bits of updated state as the FSM transitions, 6 bits of compressed output] into a 256byte block of memory aligned on 256byte memory boundaries. This removes the need to hand craft a LUT, all you are really doing is executing your logic for every possible input and caching the result.

Then the actual runtime programme loop written in assembler reads the input port directly into the lower byte of the indirect addressing register pair, debounces, merges in the 2 bits of state, immediately does the lookup, this is made very easy by keeping the LUT is aligned with a 256 byte memory boundary.

The assembler the decompresses the output bits, writes them out and updates the state bits. Repeat ad-nauseum.