CNC controller with serial (RS232) communication

[Robin Hewitt]

I am trying to get away from Windows timing problems...

Both my milling machines run on USB. When I started writing the code to do it everything seemed straight forwards. I didn't find the big snag until I added a pause button. It's not too bad, you start with a bit of panic braking and after that you have all the time in the world to sort out how you are going to get back up to speed. If it takes a whole second to sort the mess out you would never notice because the machine is paused, but it ain't easy to make it bullet proof :naughty:

I have a basic system that works and it is totally convenient to take a Win 7 laptop to the machine, plug in a USB and start cuttting but I would never describe it as commercial. I don't know of any convenient standard protocol for sending the data and interrogating the mill. All the big machine makers have their own protocols and use Ethernet. Maybe we should start a MyCNC thread and hammer out a protocol that covers all the bases and define our own standard so anyone can make the harware. I am quite happy to offer mine as a start point, but I doubt many would agree with it or even join in

[rnr107]

I doubt many would agree with it or even join in

I would! :)

Andy, Thank you for confirming! Are they any good the Smoothstepper? Does they come with a Windows software?

RNR

[Robin Hewitt]

I would! :)

Brave ! Here's a taster...

Firstly we don't know which serial port holds the USB to serial adaptor with a mill on the end of it so the software has to find it. We can draw the tool paths on the screen and have lots of neat buttons but how to find the mill?

USB devices can be either Hand Held or serial. The latter is a lot more friendly so best to go with that so as not to frighten people off writing controllers.

We can ask Windows for a list of available serial ports then send an ASCII ENQuiry character to each in turn and see what comes back. ENQ is kind of safe to send to any serial device. Now the mill is USB it can be anywhere on the list, we can't insist on COM1: it could be COM17: for all we know. The mill controller responds to ENQ with a filename, if that name exists on disk we have found a mill and we have a text file that defines it. Windows likes text files and they are dead easy to update with NotePad.

If we have more than one mill connected then we should have more than one mill definition file. The software can ask which one you want. If definition files include pet names for the mills the choice won't be gobble-de-gook. If you only have one mill definition file, it knows where to go. We could just insist you only plug one mill in at a time but how boring is that when you can run multiple mills simultaneously in different windows?

The software now hits a Windows snag. If a program doesn't release the processor umpteen times a second it will be declared as "Not responding", unfriendly and needs to be time sliced. Don't want that. My way to get around it is to start a second program that goes around in a loop, real easy to "spawn" off a new program you just write a subroutine that returns twice.

My version of this seperate program sends an 'S' on the USB which is my request for the mill status. The status will be several bytes long so while waiting for them to arrive I can releases the processor and keep Windows happy. Once I have the status I know what the mill is doing, where it is, the current feed rate, what space is available in the buffers, have we been paused etc. I can then update it accordingly, give my main program the opportunity to update the PC screen then loop back to the top for another status request.
Is anyone still with me? :naughty:

[rnr107]

I still here... understood 90% of it... :) I did not think about the multiple mill I have to say... in my case I just have 1 :)
A Boxford 260 VMC. I just don't have the physical space for more. (I had to take the 260VMC out of its enclosure to make it fit, BTW, that is not an easy task, as it is glue/cemented to the enclosure on the base. If anybody interested in doing the same, let me know I'll give you the procedure)
Would love a CNC Bridgy!

Back on tracks:
For the multiple mill we could use multithreading process using .net. We have a piece of sofware at work design to talk to 8 electronic devices on the same time via 8 COM port. It works a bit like your idea of a seperate program runing a loop in the background, exept it is an other thread / process in the main program.
As long as your CPU suppots mutithreading (I guess all do these days) then it should work...

RNR

[Robin Hewitt]

As long as your CPU suppots mutithreading (I guess all do these days) then it should work...

Doing a proper job with Windows 7 isn't hard but there is no market for it because everyone is hung up on Mach. People have tried but the only real way to do it is an open source group effort defining a protocol for sending data between PC, mill and pendant with no patents, no licences and no secrets. That way anyone can make their own mill driver boards and write software. If everyone sticks to the same standard protocol users can then mix and match competing products to find the best combination for them. Single source systems which disappear if someone goes down the tubes are not attractive, you feel too vulnerable. It needs to be a group effort because only an enthusiastic user base will suck people in.