Hello Guest it is June 24, 2019, 08:12:41 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - smurph

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.


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?


Galil / Re: Galil Status
« on: February 23, 2009, 11:44:37 AM »

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.   :)


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"..
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. 


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.


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.


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!


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!


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.


Mach SDK plugin questions and answers. / Re: PLUG IN WRITERS
« on: February 06, 2009, 08:09:32 PM »
I will get one as soon as I have enough spare play money available.  But...  I also saw some stuff on that sight from Elexol.  They have an Elexol USB I/O board that I just so happen to have.  I also have their Ethernet I/O board.  I think I'll do a PlugIn for those as well, as I already have to code I used at work that performs the setup.  Check them all out at http://www.elexol.com/ .  The USB board will probably not be fast enough, as it's basically a USB->Serial adapter.  But the Ethernet version rocks.  It has a mode by which it continually updates the host via UDP so that there is no pooling going on.

I really can't use the Futuerlec board on my machine, as my setup is all controlled by Ethernet.  But I'm sure I could find something useful to do with it.