Hello Guest it is March 29, 2024, 11:33:03 AM

Author Topic: Galil Status  (Read 31683 times)

0 Members and 1 Guest are viewing this topic.

Offline Jeff_Birt

*
  •  1,107 1,107
    • View Profile
    • Soigeneris
Re: Galil Status
« Reply #10 on: December 23, 2008, 08:24:42 PM »
Can't get what 'to work'? Yu can't get it to download? YOu can't get it to install? It does not show up in Mach? You need to provide much more information?
Happy machining , Jeff Birt
 
Re: Galil Status
« Reply #11 on: December 24, 2008, 06:10:44 AM »
Jeff,
Thanks for the reply,
O.K. what does not work? The plugin does not work, at least not on the computer I want to use. (IBM netvista dual core 3ghz 1 mb ram xp)
Mach 3.042 plugin v 3.0

Everytime I load the plugin in to Mach,  when I start Mach it gives an error message saying "defective plugin, ignoreing"

I load the plugin by pasting the galil plugin into either the main Mach folder or into the plugins folder(I have tried both), and then click on the icon. Mach will then display a message saying " plugin loaded" and the plugin icon will disapear.

I have another puter right next to this one ibm netvista 2.9ghz same version of Mach same plugin and it works but I can't get galil to recognize the network card on that pc. (Galil dmc2140 ehternet) I also can not get the galil plugin to work on any other pc I have.

Thanks,
Cutmore
Re: Galil Status
« Reply #12 on: December 24, 2008, 09:39:02 AM »
I think this has to do with the Galil driver. I had the same thing happen to me. I installed the Galil terminal program on the PC and that took care of it.

Darek
Re: Galil Status
« Reply #13 on: December 24, 2008, 09:48:47 AM »
Darek,
Thanks for the reply,
I forgot to mention that I already had the Galil termiinal installed  and communicating with the controller. The galil controller is registered in the terminal program and the windows registry also.

I know at one point many moons ago, Brian had to re-save the Galil plugin because it was corrupt or something.

Regards,
Cutmore

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Galil Status
« Reply #14 on: January 04, 2009, 12:54:22 AM »
Cutmore,

What controller?  Which version of the Galil drivers are you using?  You want SmartTerm with the version 7 drivers.  And what is the version of your Galil firmware?

Connect to your controller via the terminal and do a QZ command and then a ^R^V command (control-R control-V).  You may need to select a button to allow control key sequences.  Otherwise ^V is the Windows "paste" key sequence.  The QZ command will return the Data Record format and the ^R^V will return the firmware version.  Also do a MG_DR command.  This will let me know how the controller is handling sending the Data Records.  Let us know the results.

I bought a DMC-1760 ISA controller from dmerrll a while back.  I was wanting to get rid of an old SM-Electronik SM400 controller and use Mach.  The problem was that I have analogue servo drives so I needed something to make that tick.  The Galil looked like a good way to go.  But as you know, ISA bus machines have limited CPU frequencies by today's standards.  So I started thinking of ways to leverage the ISA based controller in a remote machine that talked to the Galil drivers on the Mach machine.  Much like a Galil Ethernet controller would. 

I used OpenBSD and wrote a device driver for the 1760 and then wrote an Ethernet front end that emulated a Galil 2100 or 2200 controller.  The results are fantastic!  The Galil Windows drivers think they are driving a DMC-2100 when they are actually talking to a DMC-1700!  This is not for the feint of heart though.  A 1 Ghz Pentium III ISA bus computer will run Mach/ISA-Galil just fine.  I was just wasting some time trying to do something something that used to be impossible.   ;D

In writing this code and wading through lots of smoke and mirrors, I learned a ton about the various Galil controllers.  Mainly what will work with Mach and what will not, and why.  So I will try and lay that out for people that are interested in using the Galil plug-in and are struggling with which controller of the day to go looking for. 

Any current Accelera controllers will work.  Stick with the version 7 Galil drivers though.

Any bus based or ethernet Optima controllers will work.  This includes the DMC1700, DMC1800, DMC2100, and DMC2200.  In theory, the DMC2000 (USB) may work as well.  I just don't know if there would be any issues with USB.  But it has all of the other necessary things to work.  Use the version 7 Galil drivers that come with SmartTerm for these controllers.  Older drivers will cause you big time headaches.

The DMC-18x2 econo controllers will also work.  But they don't support binary commands and this will slow things down a bit.  It takes about 350 microseconds for a Galil controller to process an ASCII command.  This time is saved if the controller can accept binary commands.  The Galil plug-in takes advantage of binary commands if the controller is capable.

The DMC-21x3 are like the DMC-18x2 controllers.  They might not work with the Galil plug-in because of the way they handle Data Records.  Big question mark here.
EDIT:  The DMC-21x3 controller will work fine as long as they don't have the 31x3 distributed mode firmware loaded.  If you have a 31x3, simply install the latest and greatest 21x3 firmware and you are good to go.  Also these controllers, while labeled "Econo", will accept binary commands.

There is also an older version of the DMC-21x3 called the DMC-21x2.  The difference is that the x2 controllers use the 100 pin SCSI connector instead of DB base interconnect modules for the x3 models.  So you will have to have ICM-2900s for the DMC-21x2 controllers.

The DMC-3415 and DMC-3425 controllers will not work.  These are 1 or 2 axis ethernet controllers that can be "chained" together to make a distributed controller that has as many as 8 axes.  But the way they do this is through a modified Data Record which is not compatible with the Data Record that the Galil plug-in will want to see. The Data Record is what Mach looks at (via the plug-in) to see if the state of I/O pins and DRO. 

DMC-1415 and DMC-1425 controllers will work.  But they are 2 and 1 axis, respectively.

A DMC-3425 can be updated with DMC-1425 firmware and it will work.  But you are stuck with a 2 axis machine.  Same with the 3415 except you will have a 1 axis machine. 

The DMC1000 ISA controllers will NOT work.  This is because these controllers do not have a Data Record at all.  They also do not support binary commands.  The Galil plug-in could be modified to support these controllers, but they would most likely be in the SLOW department.  Don't waste your time or money on these controllers for Mach use.

None of the VME based controllers will work.  e.g. the DMC-1300, DMC-300, or DMC-13x8 controllers.  The DMC-300 is ancient and should be discarded immediately.  The DMC-1300 suffers the same "no data record" as the DMC-1000's do.  The DMC-13x8 is an Optima controller, but the Galil windows drivers have no support for these cards at all.  Plus, unless you have a very industrial PC, you will not even have a VME bus, much less a VME bus driver.  I did, however, make a DMC-1348 controller work.  It's just that it's not feasible unless you have a bunch of VME hardware lying around.

None of the DMC-700 series or DMC-1500 series controllers will work.  They are serial communication controllers and they also don't have Data Records.  They would be good for making tool changers though.  Perhaps driven by I/O logic.

Also be aware that many of the Galil controllers that are floating around are special controllers made for an OEM.  Galil provides no support for these controllers.  Most of the time, a firmware update is all that is required to get the controller to work like a normal Galil controller.  But if there is special hardware mods, you will loose.

And a note about firmware.  Use the latest that you can get.  This is because there are several versions of the Data Record.  The version 4 and up Data Records will work.  This is what all of the Optima controllers will have if updated to the latest and greatest. 

I have to say that I really like the Galil controllers.  They are a well founded company with an excellent reputation for quality and service.  Their website provides literally every thing that an end user would ever need and drivers and firmware are available as free downloads.  Some other motion controller companies require you to buy firmware updates!  And you can call and talk to their support at any time.  They are very knowledgeable about their controllers, meaning that they are not just farmed out support.

Thanks go to dmerrll for providing me hours and hours of fun!  :)

If I ever get a copy of vs2003, I'll certainly help out on the Galil plug-in.  One thing that might be useful is the option to select a different Galil controller that runs a different machine from the same Mach controller. 

Steve
« Last Edit: January 26, 2009, 07:23:53 PM by smurph »
Re: Galil Status
« Reply #15 on: January 05, 2009, 06:44:27 AM »
Hi guys,
I have been away since my last post. I did manage to get my DMC 2140 to play nice with Mach3 ;D

Smurph,
I will get the info for you asap, I am using a DMC2140 ( Ethernet) as you know but others may not.

Turns out the problem I had was the version of Galil terminal I had on the pc.  I did not have the Smartterm on that pc, and everytime I started Mach it gave me an error saying the gallil plugin was defective.

I installed smartterm and Mach now talks to the galil! Well at least as far as I can tell, I don not have anything hooked to it yet. Now that I have gotten this far I need to buy an ICM 2900 and hook up an analog drive for the next step.

Thank you for all the help,
Cutmore

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Galil Status
« Reply #16 on: January 28, 2009, 12:35:48 PM »
Well, I got a copy of vs2003 and started hacking away at the Galil plugin along with Kenny Crouch.  Kenny added a bunch of stuff that smoothed things out as well as adding MPG support.  I've been working on things that are less visible/exciting like:

1. Adding support for controllers that do not have the rev 4 data record.
2. If there are multiple controllers configured in the Galil registry, you can now choose which of those controllers Mach will use.  Previously, Mach only used the first defined controller.

I'd like for all that have the Galil controllers running to help out testing this stuff.  That way, we can have a good cross section of results.  PM me with your email address and I will send you the plugin DLL.

Steve

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Galil Status
« Reply #17 on: February 22, 2009, 02:18:54 AM »
More Galil PlugIn stuff that we are working on:

1.  Added axis mapping.  Meaning you can now map the Galil D axis to the Mach X axis, etc... If wanted/needed.
2.  The GP I/O is now working.  However, this will require you to re-wire your Mach "ports and pins" settings.  (Not re-wire your machine!)
3.  The spindle no longer takes up a Mach motion axis.  It uses the Mach spindle instead.
4.  Support for the guys driving brushless motors via the commutation on the Galil.  (Sinusoidal Axes)
5.  Many small "gotcha" things that might pop up under certain events/circumstances are fixed.  e.g. The homing bug.

Steve

Offline Jeff_Birt

*
  •  1,107 1,107
    • View Profile
    • Soigeneris
Re: Galil Status
« Reply #18 on: February 22, 2009, 08:45:54 AM »
I'm curious about #2. The GP I/O including extended I/O was already working. What has changed that requires 'rewiring Mach'?

#3, As I recall the plug-in read the spindle status and drove what-ever axis-output you had assigned to the spindle. What is different now? If you are driving a spindle as a servo (in other words a spindle with feedback) then your using a Galil channel anyhow. The machine I put the Galil card on had a vector drive with a RS422 interface so I just wrote a plug-in to control it digitally and never messed with using the Galil to drive it so I may be missing something here.
Happy machining , Jeff Birt
 

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Galil Status
« Reply #19 on: February 22, 2009, 02:37:11 PM »
The extended I/O is still working.  There never was a problem beyond the input side of extended I/O. 

The main problem is that the GP I/O was this:

Code: [Select]
in = (Input0 & 0xFF) | (Input1 & 0xFF) << 8 | (Input2 & 0xFF) << 16 | (Input3 & 0xFF) << 24;

//first put first 32 inputs in an integer.
for (INT x = 0; x< nSigs; x++) { //check all signals from 0 to max number of signals.
if (Engine->InSigs[x].Active &&
Engine->InSigs[x].InPort == 1) { //if this signal is turned on, and its set to port #1..check it..

if ((in >> (Engine->InSigs[x].InPin -1 )) & 0x01) // if the nth (pin number) bit is active..
Engine->InSigs[x].Activated = !Engine->InSigs[x].Negated; //set it high or low depending on the "low active"..
else
Engine->InSigs[x].Activated = Engine->InSigs[x].Negated; //setting..
}
}

Well...  not that piece of code.  But pay attention that it is putting 32 bits (pins) worth of data into the input signals.  Pins 1-32, right?

Then you get to the outputs.
Code: [Select]
out = (USHORT)((Output0 & 0xFF) | (Output1 & 0xFF) << 8);

for (INT x = 0; x< nSigsOut; x++) { //check all signals from 0 to max number of signals.
if (Engine->OutSigs[x].active &&
Engine->OutSigs[x].OutPort == 1 &&
Engine->OutSigs[x].OutPin < 16) { //if this signal is turned on, and its set to port #1..check it..
bool Should = Engine->OutSigs[x].Activated;
if (Should) {
t = 0;
t  |= 1 << (Engine->OutSigs[x].OutPin-1);    
outwordM = outwordM + t;
}
}
}

Notice that the code this time puts the output values into a short (16bit) and then puts them into pins 1-16.

Wait a minute!!!!  We already put inputs into pins 1-32!  The output code just stomped on at least pins 1-16. 

Now hold on to your seats because eventually, the code goes and checks the limit switches and tries to place the values into the limits and home input signals.  Without the notion of pins or ports.  So in the "ports and pins" settings, these axis limits and home input signals need to be enabled.  But what port or pin did the user set them to?  If they left the port and pin at 0, then all would be ok.  But if they mapped them to port 1 and the parallel style pin mapping, all was not going to be ok.

Th new code sets up an explicit pin map.  This requires you to map the input and output signals in "Ports and Pins" in a prescribed manner which prevents outputs stomping on inputs which may get stomped on by the axis switches.

Code: [Select]
// Our pin layout is as follows:
// 1-6 axis pos limit  (XYZABC)
// 9-14 axis neg limit (XYZABC)
// 17-22 axis home input (XYZABC)
// 25-32 general inputs 1-8
// 33-40 general inputs 9-16 (available on controllers > 4 axis, otherwise they are logic 0)
// 41-48 general outputs 1-8
// 49-56 general outputs 9-16 (available on controllers > 4 axis, otherwise they are logic 0)

As for the spindle, the old configuration dialog only gave you the choice of setting up the spindle on the first six axes, which took up a Mach motion axis leaving you only 5 Mach axes to configure.  It was just a configuration dialog issue, the spindle code was not an issue.

I guess you are JTB in the code.  We need to talk and see if we can get the extended I/O input section working. 

Steve
« Last Edit: February 22, 2009, 02:39:04 PM by smurph »