Messages

1051

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

1052

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

1053

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

1054

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

1055

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

1056

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

1057

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

1058

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

1059

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

1060

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

« on: February 13, 2009, 12:37:49 PM »

Yeah, you are right.  You will not find many vendors interested in helping to integrate.  I used to write device drivers for the OpenBSD operating system.  And one thing I found out is that it's like pulling your own teeth without a mirror trying to get vendors to help you.  The only way a vendor will help is if they see Mach as a way of increasing their sales.  Like Vital Systems.  Smart company.  But the world is not full of smart companies.  Some start out smart and then dumb waaaaaay down.

So, in the end, you have to do it.  Or someone does.  The right combination of need and know how has to come together.  As stated, most vendors will not supply you with anything.  If you want it to work, you have to buy the product yourself and start hacking.  Or someone that is interested in getting some hardware to work may contact you and send you a board. 

Over the years, I have bought thousands of dollars worth of hardware so that I could provide support for it.  Why?  It's pretty darned fun.  A big jig-saw puzzle, if you will.  And if I think it may be useful to me, even better.  Other times, people have sent me hardware and paid me handsomely to integrate it.

BTW, the Elexol PlugIn is almost finished.  It will support both the Ethernet and USB modules in any combination up to 4 modules.  It turns out that the USB modules can be accessed via direct USB or over a virtual COM port.  The direct USB method is fast, so that is what I used.  The Elexol has 24 I/O pins per board.  Not as much as the Futurlec board.  But it does offer remote I/O.  Running one USB or Ethernet cable from the computer to the control cabinet is sometimes easier than running multiples of wires.

However, the Futurlec board has the bang for the buck going for it.  So I'd like to support it.

Steve