Messages

1511

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

1512

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

1513

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

1514

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

1515

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

1516

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

1517

Galil / Re: Mach3 + Galil

« on: February 22, 2009, 03:03:44 AM »

All of you guys with homing problems need to try out the the latest code.  It's not fully tested as I don't have motors on my Galil cards.  My motors/amps are 480v and I don't have that kind of power in my computer room, if you know what I mean.  I can view the output and it looks good, but there is nothing like putting it in action to see what it does.

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.  I think this had to do with the original pin layout.  It tried to duplicate the pin layout of a parallel port with a breakout board, but the GP I/O pins could over write the limit switches and home inputs.  So if you are trying to use I/O other than the limit switches, this could be the issue.

PM me with your email address and you will get the PlugIn along with an explanation of the new I/O pin arrangement.  But I really have to warn you that this PlugIn may not work.  As I said, I really can't fully test it yet.  But I would appreciate any people willing to try.  The DLL produces a log file in the PlugIn directory that would be of great value to help elimiate any problems, should there be any. 

I'm working on putting together a 110v system that I can test with.  But I'm still lacking some parts.  Maybe in a few weeks I can provide a better tested PlugIn.

Some things for the future include:

1. Slaving handled entirely via the Galil, thus a slaved axis will not take up a Mach motion axis.  This might free up some axes for you guys running gantries.
    You could do this manually anyway, but I'm talking about putting it in the configuration dialog where you would not have to BN your slave settings.
2. I'd really like to see ridged tapping and threading.

Steve

1518

Galil / Re: Galil Status

« 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

1519

Mach SDK plugin questions and answers. / Re: PLUG IN WRITERS

« on: February 19, 2009, 02:05:50 AM »

The Elexol PlugIn is finished.  If anyone wants to try it out, you can download it in the Finished PlugIns section.

It turned out really nice!

Steve

1520

Finished Plugins for Download / Elexol I/O 24 PlugIn

« on: February 19, 2009, 02:02:48 AM »

This is a PlugIn for the Elexol I/O 24 modules.  http://www.elexol.com

Up to 4 modules can be configured (Ethernet or USB), in any combination, for a total of 96 I/O pins.

The PlugIn utilizes a feature of the Elexol modules that eliminates polling.  So there is not much traffic in normal situations.  The USB modules are a breeze to setup.  Ethernet modules require a bit more knowledge, but there is setup software available from Elexol that makes it as painless as possible.

These are great little modules that can eliminate many cables from the Mach computer to the machine.  They can be used in conjunction with parallel port setups as the Mach port that each module uses is configurable.

If you like the idea of these modules, I would suggest getting their opto-isolated input boards and their relay output boards.  They will handle 24v systems this way and the risk of frying something is reduced.  Otherwise, the inputs and outputs are 5v TTL.

You can download the PlugIn here -->  http://www.smcomp.com/~smurph/Elexol/Elexol.m3p
And the documentation here --> http://www.smcomp.com/~smurph/Elexol/ElexolPlugIn.pdf

I hope you enjoy!

Steve