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

841
Galil / Re: Galil controller compatability (what works with the plugin)
« on: February 05, 2011, 08:31:04 PM »
Your AC DC settings come from Mach settings in Config->Motor Tuning.  You need to set the counts per unit correctly as well.

You might want to read the Mach documentation a bit more to get an understanding on what is required in the Mach settings.  They are geared to the parallel port, but the concept is the same no matter what control you are using.  You will then be able to put all of the pieces together.

You need to do this for all of your axes:

1. Enable the axis in Config->Ports and Pins (motor tab).
2. In motor tuning, set your counts per unit, the max seed, and acceleration.  (This is where your problem is)

Then, in the Galil plugin config:

1. Map the Mach axes to the Galil axes.
2. Set the motor types.

Do not map multiple Mach axes to one Galil axis.  Meaning each Mach axis requires a unique Galil axis.

The PID settings should be the only thing burned into the Galil's NVRAM.  All other settings are calculated from Mach settings (which HAVE to be correct for your machine).

Disable the MPG until you get the Motor Tuning corrected.  It can make things harder to diagnose.  Also, set the motor type for your E and F Galil axes to servo to get rid of the SM jumper warning.

Steve

842
Galil / Re: Galil controller compatability (what works with the plugin)
« on: February 05, 2011, 10:44:34 AM »
None of those step/dir parameters are required.

843
Galil / Re: Galil controller compatability (what works with the plugin)
« on: February 05, 2011, 12:05:19 AM »
I don't know why you had problems with the plugin, as it has been at version 4.4 for a good while now.  Neither Kenny nor myself have updated the website.

To run a servo, the plugin needs the motor type to be set to either "servo" or "servo reversed" and the stepper jumpers on the Galil for that axis need to be open.  Also, the KP, KI, and KD parameters need to be burned in the NVRAM.

Verify that you can get axis movement in SmartTerm or Galil Tools before trying to configure the Mach plugin.  Please read the plugin documentation about turning on debug output and send us a GalilDebug.txt file if you continue having problems.

Steve

844
Galil / Re: Galil controller compatability (what works with the plugin)
« on: February 02, 2011, 11:08:55 PM »
That error means that the plugin could not find some support DLL.  The plugin is linked against these Windows system DLLs.  These should all reside in the System32 directory. 

dmc32.dll (SmartTerm)
dmcser32.dll (SmartTerm)
VERSION.dll
KERNEL32.dll
USER32.dll
GDI32.dll
comdlg32.dll
ADVAPI32.dll
COMCTL32.dll
SHLWAPI.dll
ole32.dll
OLEAUT32.dll

Sometimes a bare bones Windows install does not provide all of these DLLs.

Steve

845
Galil / Re: unexplained stop during program
« on: January 30, 2011, 06:23:30 PM »
Steve,

I sent you a new plugin to try.

Steve

846
The advantage the Ethernet has over USB is purely for the developer.  Once you beat it into submission, the devices perform quite well.  There is nothing wrong with USB.

I use Galil controllers.  http://www.galilmc.com/  The Vital Systems DSPmc also uses Ethernet.  Mesa http://www.mesanet.com/ is prototyping an Ethernet device as we speak and they already have a USB and PCI/PCIe devices.  Smooth Stepper is what I would be using if I was driving steppers.  It flies!  I saw a machine running it and I was super impressed.  Then there is K-Flop too (That one looks nice.  I wish I could see it in action as well.).

My point is that external motion devices are the future.  USB and Ethernet.  There will be plenty to choose from that are within the grasp of the hobbyist.  And once someone converts from the parallel port to one of these devices, they will wonder why they didn't do it sooner.  The speed and smoothness are "unparalleled".  (pun intended.  I could not resist!  :) )

Steve

847
Yes.  That is exactly how I control a Galil Ethernet controller with Mach.  Typically, you want to have your controller on it's own network.  The simplest most direct way is to connect the Ethernet card in the PC and Ethernet motion device with a crossover cable.  No router or switch required.

But...  If your network is in good shape, meaning that it's functioning properly and not over utilized, then communication from the PC through a switch to the motion device is perfectly acceptable.  I have a 10Mb old school network that I use and it rocks.  The latency is in nanoseconds as compared to milliseconds with USB.

Steve

848
*Off Topic*I am curious about the USB comment you made, what would they replace it with? SATA? I haven't really been keeping up on the new tech. Im pretty sure my spare computer I run right now(My gaming Comp. died) runs USB 1.0. lol.

I don't know for sure.  It might be PCIe external.  But that is an expensive proposition right now.  It will get cheaper.  And buy the time USB 3.0 is done, there will probably be a new kid on the block anyway.  But don't count Ethernet out.  They have about got the price of an Ethernet interface down close to that of a USB interface.

USB will hang around simply because of the shear number of USB devices out there.  However, I do have some USB devices that don't work with Win 7.

For the end user, USB is very appealing.  Plug and play.

But there are problems with USB that people (motion developers) want to get away from.  Namely latency.  Especially with the Windows OS because USB support was grafted on.  Remember that M$ didn't WANT to support it because it hit the Apple first!  So it is kind of stuck on like a sore thumb in Windows.  The Windows scheduler is what is responsible for initiating the outgoing stream.  By default, a packet is sent every 16ms, if there is data to send and it is less than 64 bytes.  You can trim this down to 2ms with some USB devices.  And you can also do tricks like forcing the packet to 64 bytes.  In short, sending short packets at a high frequency is challenging.  So what developers HAVE to do is some sort of buffering to ensure that data gets to the device in a smooth enough stream with a quantity of data that is large enough to hide the latency. 

Another problem with USB is that it does require a device driver.  (same is true for PCIe and friends) If the maker of the USB chip set stops supporting it and decides not to write a device driver for the OS of the day, then it will run into obsolescence leaving the poor hardware developer hanging.  Ouch.  So something that doesn't require a device driver really looks nice to a hardware developer.  (Ethernet anyone?  :)  )

I believe that low cost Ethernet based motion devices are on the horizon.  (That's a hint!)

Steve

849
Galil / Re: Gantry homing problem
« on: January 20, 2011, 12:13:23 PM »
Make sure that the "Home slave with master" is not checked in the Mach General Config.

The Galil plugin puts the master/slave axis in gantry mode.  But if Mach sends movement commands to the slave axis, then the movement of the slave axis is doubled!

In the next release, I will handle this case in the code so that no matter how the General Config is setup, it will do the right thing.

But...  as Kenny said, a GalilDebug.txt file would be nice to verify this.

Steve

850
Like I said...  things change.  The segment of machines that you can even add a parallel port to is growing smaller by the day.  The writing is on the wall.

For Mach, the question is whether to invest the required resources (time and money) into a dying technology.  It will become a business decision that will be quite simple.  And we may already know the answer.

Steve