Galil Status

[Jeff_Birt]

I think the problem is your confusing the logical constructs inside Mach (like limits and Inputs1-16, Outputs 1-16, etc.) These have nothing to do with the LPT Ports&Pins. Using the Ports&Pins you map a PHYSICAL LPT I/O pin to a LOGICAL construct inside Mach, your mapping Real world I/O to Machs internal registers for keeping track of the state of the machine. When you are using another I/O device like the Galil or SS it is the driver's/plug-in's responsibility to map the real world I/O from the device (NOT the LPT) to the same logical constructs in Mach. If you then turn around and try to map the LPT pins to the same logical constructs inside Mach you have told Mach to get the same information from TWO different places and all you get is confusion.

Engine->InSigs

• and OutSigs
• are arrays that represent the state of what is labeled as Input 1, Input 2, etc. They have nothing directly to do with the LPT pins BUT though ports and pins you can map an LPT pin to one of these array elements. So as Mach goes through its loop it looks at the LPT and copies what ever state that physical pin is in to that array element. If your using another control device like the Galil, the plug-in is mapping the control devices state for that signal to that array element.

Port 0 in Port and pins means 'not a real LPT', 'the signal comes from elsewhere'. The Galil plug-in only cares about the check-boxes that have to do with being enabled and whether the signal should be inverted or not. If you have an external control device and set the port to anything other than port zero then you'll get garbage.

I think the current implementation of Ports&Pins is dated and only causes confusion when using something other than the LPT. Hope that helps...

[smurph]

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:

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

[Jeff_Birt]

The issue comes about because your mapping a real I/O port (LPT1) to the same registers that the Galil is writing to. Ideally Mach would just disable setting the port to anything but zero when using an external motion card.

[smurph]

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

[poppabear]

Hey Steve and Kenny,

   I tried to compile the 3.0 source from the cvs, and I get this error:

Project : error PRJ0019: A tool returned an error code from "Performing registration"

any clues?

it is the only error I am getting.

scott

[smurph]

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
 

[poppabear]

well it will compile now, BUT......

It will not load, as I load Mach3 I get a .dll Plugin defective warning, followed by a "galil.dll" plugin defective and it says ignoring......
when I go and try and find it to enable it, it is not in the plugins list, since it has been ignored......

I dont know why it is saying it is defective, it compiles well, no errors.

scott

[HillBilly]

Hey Scott,

I had this happen to me. I installed Galil smart terminal and it cured the problem.

Darek

[poppabear]

Steve & Kenny, (and Darak),

   Kenny I put the galil.dll you sent me into mach3 plugins, Darak I downloaded and installed Smart term 7.

We are a little closer, but still no cigar.....   I can now see the Galil plug in as an option in my plugin config, BUT!!!  As soon as I enable it
it CRASHES Mach instantly!!!!  I get the choice to debug, or retry, or close, but no matter what choice, it dies....  I tried it several times...

Some possible issues from my end that may be causing the crash are:

1).  I dont actually have a Galil Card hooked to the Laptop since I am just trying to get the plugin to run.
2).  Unfortunatly, I have a new laptop, since while in TX last week, my laptop dropped and died....  I had to goto
best buy and get another one to complete my job there. My ONLY choice was a Vista 64 powered Laptop there was not
any 32's and definatly no XP......... 
Since I was running Vista 32 on the old laptop, I got Mach3 working and VS2003 working again on it, pain in the ass work around
but do-able.

If I have to have a Galil Card attached, then just let me know and I will shut up, for now until I get one. BUT, I am stuck with the new Laptop
I did find out that if I HAVE to, I can "Down Grade" to Vista 32, since the laptop I bought has drivers avail for both 32 and 64 systems.

Let me know,

scott

[Jeff_Birt]

Scott, you need to have a Galil card installed. The plug-in asks the Galil driver for the address of the first installed card. My guess is the it is not handling the case when it gets a NULL pointer returned and so it crashes. As 90% of the plug-in involves trying to talk to the card it would be a mess trying to see if a card actually existed in all those cases. Probably a check could be put in after the request for the card address and a flag could be set to indicate a card was not found. Then the update loop could be skipped if a card was not present. It wouldn't crash that way but you also couldn't do anything with it.