Hello Guest it is September 23, 2020, 08:09:36 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

941
The ICM can use the logic level voltages that are present on the ICM (+5 and +12).  There is LSCOM and INCOM which are the common rails of the limit switch inputs and the general purpose inputs.  I usually tie +24 volts from an external supply to these common terminals.  I do NOT recommend using the logic level voltages on mechanical switched circuits.  So 24v is pretty much mandatory.  This sets the circuit up for the switches to ground the circuit.  Each of the wires tied to an input or limit is then tied to one side of the switch and the other end of the switch is tied to ground.  Either normally open or normally closed switches can be used.  However, for safety reasons, I would recommend that the limit switches be the normally closed type.

The output wiring depends on if the ICM is opto-isolated or not.  If it is, it will have a -OPTO label on it.  You would then supply OUTPWR and OUTGND.  Read the Galil documentations for examples of wiring the output circuits.  i usually use the outputs to drive solid state relays regardless of if the ICM is -OPTO or not.  Then you can use the logic level voltages from the ICM to control the output SSRs and let the SSRs switch what ever voltages you need.

The general inputs and outputs (8 each on your 1842 board) are not used for anything special on the Galil.  They are merely there for machine I/O duty.  There is one exception, however, and that is the case of probing.  Inputs 1-4 also serve as the high speed position latch triggers.  So if you want to use a probe, do not use these inputs for other purposes.  The triggers are PER Galil axis.  Input 1 is for axis A, input 2 is for axis B, etc...  So if you are using Galil axes A, B, and C to drive Mach axes X, Y, and Z, then you will want to reserve inputs 1, 2, and 3 for your probe inputs.  Each input should be wired up to the probe so that a probe strike activates all of the inputs at the sane time. 

Steve

942
Galil / Re: Install Error
« on: March 04, 2014, 03:27:13 AM »
Yeah, that one got me too years ago.  I found myself trying to double click the line or the check box.  I'm glad I'm not the only one that suffered this!  :)

Steve

943
Galil / Re: Galil ICM 2900 7407 enable IC
« on: March 04, 2014, 03:23:46 AM »
For future reference, the part number are SN7406N and SN7407N.  Both available from Digikey.

For the 7407: http://www.digikey.com/product-detail/en/SN7407N/296-1436-5-ND/277082
For the 7406: http://www.digikey.com/product-detail/en/SN7406N/296-1435-5-ND/277081

Steve

944
Galil / Re: icm 2900 screw connectors
« on: March 04, 2014, 03:05:21 AM »
They are a pretty common connector.  I purchased them from Digikey or Mouser Electronics.  There is a top access part number and a bottom access part number.  But I ordered just top or bottom (I can't remember which) and they will interchange but just not wire up as nicely.  If I can find my receipt from waaaaaay waaaaay back when, I'll post up the part number.

Ahh...  Here it is.  http://www.digikey.com/product-detail/en/ELFF04230/APC1176-ND/1787967  They only have the top access ones in stock. 

Steve

945
Yes... stepper or servo?

The pins pretty much are how you map the Galil inputs and outputs.  The pin map is in the Galil Plugin PDF.  Basically you find the input or output you want and look up in the PDF and you assign that pin number yo the Mach input or output signal you want to map it to in "Ports and Pins". 

The encoders are internally mapped, so don't do anything on the "Encoders" tab of the Mach config.  Just make sure the encoders are wired up to the ICM.  The AMPENA output on the ICM is also internally mapped.  It is actually toggled high with the Galil command "SH" and low with "MO"  The plugin issues these commands to the Galil appropriately. 

Steve

946
Galil / Re: Problems with losing position
« on: March 04, 2014, 02:38:49 AM »
If you would not mind could you try to explain the gear ratio part of Mach.
I keep reading that section, but I just do not really get it

In Mach, we need to know the amount of encoder counts that results in 1 unit of measure.  If you set your machine up for inches, then we want to know how many encoder counts/steps it takes to move the axis exactly 1 inch.  Hence the term Steps per Unit.  One of my machines is 12700 steps per inch.  This is inclusive of any gear reduction!  But in the end, we don't care about the gearing.  Only about how many steps it takes to get to one inch.  If you set Steps Per Unit in "Config -> Motor Tuning" to this value for each of your axes, you can't go wrong. 

Mach allows each axis to have a different steps per unit.  In a simple scenario like a 45 degree angle cut, X may move 2000 counts and Y may move only 1000 counts.  But if the steps per unit for X and Y are correct, they will both move the same distance and thus produce the 45 degree angle.  This works fine in Mach because we told the machine to move a certain distance that is based in the user units for X and Y.  This is a lot tougher to deal with on the Galil because you are not dealing with distances.  You are working in encoder counts!!  1000 counts on X would be exactly half of the distance of 1000 counts in Y in the 45 degree angle scenario. 

So in Galil code, you have to do a little math in your head to extrapolate a distance based on the number of counts it takes to get there for any particular axis.  In stead of saying "G01 G91 X1 Y1" in Mach, you would give the Galil a command of "PR 2000, 1000" to do the same move.  PR is "Position Relative" (incremental move) and is equivalent to G91 in G code.  So you can see here that having the same number of counts to move each axis a certain distance is VERY beneficial when working in the Galil environment.  It makes things a lot more simple.  Now, how about plotting a circle with X and Y counts per inch being different?  Boom!  Mushroom cloud!  At least in my head it is. 

This is not an issue in Mach because Mach does all of the math for you.  Isn't Mach wonderful?  Thank you Mach!

Steve

947
Galil / Re: Problems with losing position
« on: March 03, 2014, 11:45:30 AM »
Matt,

I'm glad you found the issue!  Those things can be hard to diagnose for the very reasons you stated.  

And you also raised a really good point about drive ratios!  Galil does provide some relief for mismatched ratios or encoder counts with the ES command.  But it is limited to Vector Mode operation.  So it is best to have the ratios the same to reduce headaches.  Trying to code a circle in Galil code with different axis ratios can make one's head explode...

Steve

948
Galil / Re: Problems with losing position
« on: March 01, 2014, 12:29:24 PM »
No, it has not been updated.  I will have to build a full release and get the web gods to comply with a small sacrifice of some inanimate object.  :)

949
Galil / Re: Problems with losing position
« on: February 13, 2014, 07:21:33 PM »
I'm running Version R3.043.062.  But I'm sure the newest Mach3 Rev. would also work.

Steve

950
Galil / Re: Problems with losing position
« on: February 13, 2014, 12:08:27 PM »
Yes.  But you can only be assured it works with XP32 and Smart Term.  :(  XP is a bit long in the tooth these days and MS will drop support for it in 2 months!  But if you get a machine that is stable with it, you should be able to run Mach3 on XP for quite a while.  Just remember that if something goes "poof", you will have a hard time getting it replaced as compared to just buying a new PC and going from there.  Most new PCs don't even have the good 'ol PCI slots anymore.  :(

I recommend any Ethernet controller.  21x3, 21x0, 22x0 for the older ones.  41x3 and 40x0 for the new ones.  The new controllers are really fast.  They take input from the command line approximately 10 times faster.  They also have a new motion mode called PVT (vs. linear interpolation) and can also use contour mode.  Ethernet will be around for a really really long time.  And it requires no driver from Galil that may become antiquated by new Windows versions or hardware changes.

Steve