Program that sends G-code pages to a machine tool's controller

[RPJ]

I am looking for some advice and examples (if possible) of programs that are able to send G-code programs to a CNC machine's controller.

In other words I would like to build a program that could send the G-code program to the CNC brain of a machine tool (possibly through the serial port of the computer) . Also, I would like to read back programs from the CNC brain of a machine tool, bring them on the screen and possibly write an ASCII file that could be opened with notepad or word.

Could somebody help?

Thank you

[Dennis_Knutson]

Just reading or writing the G-codes is usually pretty simple. If the controller has a serial port, then all you need to do is configure the serial port and then do a VISA Write to send the codes and a VISA Read to get them back. In both cases, you'll need to know the command to send to the controller to prepare it for a new program or which program to read. The controller should have some doucmentation that explains this. I would recomend that you test the communication with something like Hyperterminal first and then run one of the shipping examples. Search the examples for serial. One thing that you'll probably need to be aware of is that Hyperterminal automatically appends control characters (CR/LF) to the end of each command you type. In LabVIEW, you have to add these yourself.

[Dan_Quinn]

Hi RPJ,

I'm not sure if this is an option for your application or not, but there is actually a toolkit available that allows you to control CNC machines with G-Code using an NI-Motion device such as a PCI-7344. The company that developed this great toolkit is called ABMSoft (www.abmsoft.com) and you can find some more information here as well:

http://sine.ni.com/apps/we/niaa.ind_pro_view?p_all_id=7974&p_display_all_id=7984

Is that an option for you or do you need to use your current controller?

Dan

National Instruments

[RPJ]

I would like to thank to both enthusiasts that sent me an answer. Dennis is much closer to what I want to do. I looked at the shipping examples but I am not sure how to adapt them to the communication with the machine tool...

I was wondering if Dennis would have an example of such communication through the serial port. It would help better.

Thank you

[Sheldon_Stokes]

I think you want to use the parallel port rather than the serial port.  I've done what I think you want to do, but not in LabView. 

I have a Taig benchtop milling machine that I built my own stepper control box for (based on the allegro chips).  It like every hobby CNC machine I've seen uses step and direction lines for each axis.  IE, when the direction line is pulled high, each pulse on the step line moves one direction, when the direction line is pulled low, each pulse moves the stepper the other way.  This very low-level of control is quite popular in CNC machine tools and allows the controller to blend axes for circles etc. 

You've got a couple issues with trying to do this level of stepper control with LabView, the main issue is windows itself, the latencies out the parallel port is quite long due to the hardware abstraction layer in windows.  Second is the lack of determinism in windows.  So even after your pulses (IE data) start spewing out the serial port, there is no guarantee that all your data will come out in a smooth consistent manner.  Rather, there will be a splatter of data, a pause while windows does something else, then another splatter of data. 

This is a real issue when controlling either steppers or servos with step and direction type of controls.  Because the step pulse train is directly linked to motor speed.  Any fast changes in the pulse train period will cause motor stalls or other very undesirable behavior.  You can get around this to some extent by working very slowly.

My workaround is to use TurboCNC (you get the source code when you register), which is a turboPascal program that runs in DOS.  DOS is so simple that it's quite deterministic and you can get nice consistent pulse trains out the parallel port.  I use various windows programs to build my parts, and generate G-Code (Autodesk inventer, meshcam, MasterCam, etc).  I've also written some, not-for-prime-time, Labview routines to edit G-code, view toolpaths, and unroll loops, etc. 

To use a non-real-time OS to control real-time critical tools like this, you can always build a hardware buffer.  Imagine a hardware Queue where your pulses are pushed into one side of the queue sporadically, and a hardware clock pops them out of the queue to your controller in nice smooth increments.  I've been toying with building such a thing, but honestly, the DOS turboCNC program works so well that it's not high on my list. 

The beauty of DOS and turboCNC is that you can use a $40 small laptop to control your machine.  I have a 486 HP laptop sitting on top of my controller next to my mill.  Small, cheap and effective, everything I want. 

Pushing your data out of the parallel port is fairly easy in LabView, and parsing G-code is also quite easy, but before you spend much time on it, make sure the data coming out your parallel port is suitable for your needs from a timing standpoint.

Hope that helps,

Sheldon

Message Edited by Sheldon Stokes on 09-27-2005 09:01 AM

[RPJ]

WOW!

Your message was impressive. Thank you.

However, it is Dennis who figured out exactly what I want to do. I want to send the G-code programs to an existing CNC machine or to read back the programs using LabVIEW capabilities. For example I can write a G-code program in notepad then I can copy and paste the G-code program in a labview window ; then I tell the LabVIEW peogram to send the G-code program (through the serial port) to the machine's controller; then I can call the G-code program by its name on that machine at any time even my computer is disconnected for example; in other words, now, the G-code program is in the memory of the machine. If I want to import a G-code program I use the same LabVIEW program which this time reads back from the machine.

I hope I was not too confusing.

Thanks again.

[Dennis_Knutson]

I used to have a program that read an AutoCad dxf file, converted it to g-code, and wrote to a Fanuc controller, but that was a couple of jobs ago and it's not something I saved unfortunately. The attachment shows the basic procedure for reading a file and then writing it to the serial port. What you'll have to add is the special commands that tell the controller to prepare to receive a new program. This would go after the VISA Configure Serial Port. If you can attach an electronic copy or post a link to a description of the controller's communication protocol, someone could probably help you with this if you have problems.

[RPJ]

Thank you. I will look into that.

[YasSU]

Hi RPJ,

I know it is a long time after. I was wondering if you made it happened and if so would it be possible for you to share your file with me.

Thanks,

[RPJ]

Hi YasSU,

We found a different method at that time so I did not pursue the program based on LabVIEW.

Sorry I cannot help. Maybe other enthusiasts can help with this topic.

One challenge may be the fact that various machine tools have different ways of communication with the 'ouside world'(e.g. some use RS232 ports, others use Ethernet etc.)

Good Luck!