Messages

1021

Galil / Re: Mach3 + Galil

« on: April 09, 2009, 12:31:52 PM »

Version 4.0 of the Galil PlugIn has been released.  You can download it from the PlugIns download section.

Direct MPG support - The smoothest MPG jogging you will ever see!!!  (Kenny is the man!)
Axis mapping - Allows sinusoidal commutation axes to work plus greater freedom while commissioning the machine.
Smoother user interface (DROs and toolpath).
Probing support - G31 probes are now supported.  (However, the 3d probing plugin is not supported.)
Choice of two motion modes - Linear interpolation and contour mode.  You can choose which one works best for you!
Each different Mach profile can use a different Galil controller, if required.
Accelera (the latest and greatest from Galil) are supported.

Along with the PlugIn, there is a PDF user manual.  Be sure and read it as there are differences in the way input and output signals are handled (Ports and Pins) as compared to the V3 Plugin.

The Probing requires a special setup and it is not in the documentation as yet.  I will try and get that documented as soon as possible.

Thanks to all who tested this Plugin!

Steve

1022

Galil / Re: Galil Status

« on: March 29, 2009, 01:03:11 PM »

Scott,

It's trying to run regsvr32 on the resulting DLL.  Look in the project properties, build events, post build events and you will see what is going on at the end of the build.  I'm not sure if the DLL even needs registering, but there it is.  It may be a path problem.

Steve
 

1023

General Mach Discussion / Re: Spindle speed syntax error

« on: March 27, 2009, 10:51:07 PM »

In BASIC, you use a colon to separate multiple commands on one line.  You might look for the magical colon on your other three machines.  Or try it.  I have no idea if it even pertains to the VB in Mach.

Steve

1024

General Mach Discussion / Re: Need Galil Help

« on: March 27, 2009, 01:48:18 AM »

Are you using steppers?  If so, click the "use Ref position not encoder for position feedback" check box in the plugin config. 

PM me with your email address and I'll get you the latest Galil Plugin. 

Steve

1025

Galil / Re: Mach3 + Galil

« on: March 25, 2009, 03:05:31 PM »

All of the needed stuff is in the 2040 controller, but USB has never been tested.  It would really depend on the speed of the USB connection.  Some vendors choose to emulate a serial port with their USB interfaces and they are subject to the speed limitations of the serial port.  I have no idea if this is the case with the USB Galil controllers.

They only way to know is to try it.  I've been trying to find a USB controller to test with, but no joy at this point.

If you have a USB controller, try it out.  If you don't have the controller, consider getting a PCI or Ethernet controller instead.  I much prefer the Ethernet controllers as it allows for the controller to be placed in the machine control cabinet.

Steve

1026

Galil / Re: Mach3 + Galil

« on: March 14, 2009, 09:11:33 PM »

Yes, I have thought about writing a PlugIn for the AnythingIO boards.  But I had all a few Galil Controllers laying around and decided to use them instead.

While some Galil controllers are PCI based, there would be no other similarities to the Mesa cards.  Galil provides an API library to access the controllers.  Mesa does too, but the APIs are totally different.

EMC2 uses the HOSTMOT configuration.  This is the configuration where the host closes the loop and it requires a real time operating system.  For Mach, the SOFTDMC configuration would be the choice.  It could be done, I'm sure.

Keep in mind that in order to run analogue amps with the Mesa boards, you will need their PWM to analogue converters as well.

What would it take for a Mesa Plugin to appear?  Well...  form the looks of the current PlugIns available, they come to life in one of four ways.

1) A programmer that likes to play CNC has a device that he/she wants to use and then they make it so. They may choose to "give" this PlugIn to the Mach community.
2) A manufacturer has a device that they want to run with Mach.  (Vital Systems)  They hire (or have) a programmer to write the PlugIn to insert themselves into the Mach market to sell the hardware device.  A commercial venture, so to speak.
3) A programmer writes a PlugIn for a device, that he/she thinks will be desirable in the Mach market, to sell the PlugIn.  Another commercial venture.
4) Art or Brian just gets froggy and decides to write the PlugIn for reasons of their own.  (Galil, G100)

I would probably write a Mesa PlugIn if I had the Mesa hardware.  But since I don't have the hardware and I already have Galil hardware, I can't justify buying the Mesa stuff.  If I bought the hardware just to write a PlugIn, the resulting PlugIn would most likely not be free as I would want to recover my investment in the hardware.  It's a lot of work.  You need a computer with Mach, VS2003 compiler, and the hardware device in it, all sitting very close to a test machine with motors on it.  And hours upon hours of time to spend on it.  I can't even begin to count the hours I have spent on the Galil PlugIn.  There are 4 people that have contributed to the Galil Plugin that I know of.  Brian, Jeff Birt, Kenny Crouch, and myself.  I would imagine that the total man hours spent on it's development is probably quite staggering. 

So for now, if you want to run a closed loop servo system, your choices are the Vital Systems DSPMC/IP and the Galil.    Or, if you wanted to write a plugin, both the Galil and G100 PlugIn source are in the Mach SDK.  You can look at them and learn about what information Mach can send to the PlugIn.  But the actual implementation for the Mesa is bound to be as different as the difference between the Galil and the G100.

Steve

1027

Galil / Re: Mach3 + Galil

« on: February 27, 2009, 12:44:44 PM »

Here is a link that will answer most of your questions.  http://www.machsupport.com/forum/index.php/topic,2156.msg61995.html#msg61995

The 1000 Series cards are not supported.  (No Data Record)  Support for the latest and greatest Accelera cards has been included, but not tested.  You will need the latest SmartTerm Version 7 Drivers.  You can also install and use the GalilTools on the same machine, but the Version 7 drivers are required.

Steve

1028

Galil / Re: Galil Status

« on: February 23, 2009, 02:23:49 PM »

I don't know...  I think the way Mach does it now is a very flexible way of doing it.  But with flexibility comes complexity sometimes.    And that is true with the Galil PlugIn as well.  It is getting more complex, but definitely more flexible.   We need a way to map your ext I/O so that it can be configured to work with all configurations/PlugIns.  But geeeees what a job that would be.  Talk about getting complex. 

What are you using your extended I/O for?

Steve

1029

Galil / Re: Galil Status

« on: February 23, 2009, 11:44:37 AM »

Jeff,

You are right, it is confusing.  But I have written an I/O plugIn that use ports other than zero.  In fact, you can set the port to 10 if you wanted to as long as the signal mappings in "Ports and Pins" agree with the PlugIn.  With the Galil code, it had the notion of port 1 for the GP I/O.  See the

Code: [Select]

Engine->InSigs[x].InPort == 1 in the code.  It was the limits that had no notion of ports and pins.  Which was fine as long as none of the limits were mapped in ports and pins.  If they were, there stood a chance of getting the real signals overwritten with whatever was mapped in ports and pins.

All I am saying is that the new pin layout provides a means of ensuring that no signals get stomped on.  And that was a very real possibility with the old way of doing things.  It may have worked before, but it works better now.   

Steve

1030

Galil / Re: Galil Status

« 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