Galil controller compatability (what works with the plugin)

[smurph]

It's possible.  I have a few 1425s and I'll pound one to see if I can get it to choke up.  They are a little bit different than the Optima line.  I put the support in the plugin for them just because I had a few laying around.  But I didn't do any thorough testing with them.  Just got them talking.   I was planning to try using two of them with the distributed firmware (makes them a 3425) for a total of 4 axes.  I'm not sure that distributed mode will work for axes that need to be tightly coupled, but it might work for controlling a Z axis and spindle for a 2D mill type of setup.  Or a lathe that needs spindle control.

Steve

[Swap_File]

It stopped again (with the new plugin).  This time there was no error message in Galildebug.txt.  Mach3 stopped executing Gcode and I had to exit out of Mach3 and relaunch it to get it to work again.

Attached is the Galildebug.txt

[Swap_File]

Tomorrow morning I am going to unhook all my limits for testing, there is a possibility they could be flaky.  I've noticed that sometimes a noisy limit can silently trigger the Galil without showing up in Mach3.

[apukak]

I tried the new plugin, but nothing's changed, the system stutters. (cca. 400ms is period.)The mach is very occupied.  Repeatedly push the STOP button  in order for the machine to stop.

[smurph]

Something must be going on with your machine.  All indexing and other OS functions (Automatic updates, etc...) that burn CPU must be turned off.  Look at this link and see if there is anything that needs to be done.  http://www.machsupport.com/downloads/XP_Optimization.txt

Others are reporting success with the improved timeout handling.

Steve

[apukak]

The mach runs well if the output is a parallel port.
The mistake comes forward only with the galil.

apukak

[smurph]

Make sure that the GalilDebug.txt file is turned off in the plugin.  It could be that!  A 300000 line Gcode program may create a HUGE debug file.  And the bigger the file, the longer it takes to seek to the end and write a new line.

I'm really grasping at straws here because I don't know where else to go.  If that doesn't help you out, I'm afraid I have no more suggestions. 

Steve

[Swap_File]

That special plugin is working great with my DMC 1425.  No problems with Timeouts, and I don't notice the machine stopping at all.

I am still keeping an eye on my Galildebug.txt.  Should I be seeing anything when it catches a timeout?

[Swap_File]

I have noticed different behavior with the 4.5 plugin and my DMC1425 versus the 4.4 plugin with my PCI DMC1800.

When I trip an limit or E-stop button with 4.4 and my DMC1800, mach 3 goes into E-stop mode instantly, and the machine stops instantly.

When I trip a limit or E-stop with the 4.5 special plugin and my DMC1425, mach3 goes into E-stop mode instantly, but the machine will keep executing commands for a bit (maybe a second?) before it notices the E-stop.

Also, if I am holding down an arrow key to jog the machine, and trip a limit, mach3 will go into E-stop mode instantly, but the machine will keep jogging until I let go of the button.  Once I let go of the button, the machine will stop completely and remain in E-stop mode until reset.

It's almost like the plugin doesn't notice that Mach3 has entered E-stop mode.

Ideas?

[Swap_File]

As a temporary solution I have wired my limits to my ABORT input on my DMC1425, and jumpered ABORT to the input pin I have assigned to E-stop in Mach3.