Hello Guest it is March 28, 2024, 07:32:02 PM

Author Topic: Upgraded to win7 on PCI system - now weird VFD behavior  (Read 8430 times)

0 Members and 1 Guest are viewing this topic.

Upgraded to win7 on PCI system - now weird VFD behavior
« on: September 15, 2012, 02:57:40 PM »
Hello,

I recently upgraded my cnc computer to an i7 Celeron running windows 7.  I am using an 1840 PCI card (I was running XP on an old Pentium 3 with a 1740 card for 4 years).

I installed Smarterm, but I had to manually install the version 7 driver in the system32 folder and go through device manager to get the driver registered.  I could not get windows 7 to install the drivers due to them not being digitally signed and Galil does not support or recommend them for use with w7.  I've read through the Galil notes and verified all the needed drivers are now in my windows/system32/drivers directory.

Anyway, things went smoothly after that and all three axises move fine.  The problem is getting the VFD to work correctly.  M3 and M4 commands work fine and the spindle starts, but usually turns very slow.

I've found that going into the configuration of the Galil plug-in on the "Axis Setup" tab and selecting/de-selecting the Spindle has Encoder" box will usually get the VFD to work right.  Sometimes it takes a couple attempts, but once going, I can run all day.  

Barring going back to XP, is there anything I can do to fix this bug?  I'd prefer to keep w7 if possible.

Any help is appreciated.

Jim  

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #1 on: September 21, 2012, 08:43:41 PM »
Wow...  That is a weird one!

All the check box does is control whether or not to use a JG command or an OF to run the spindle.  It does no other magic.  

I assume that your spindle does not use an encoder.  If that is the case, then the KP, KI, and KD parameters for the axis driving the spindle all need to be set to 0 and burned with the BN command.  Otherwise, you need to have proper PID values to use an encoder.

Maybe your previous card had the PID set to zero and you new one doesn't.  That is the only thing I can come up with.  

Steve
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #2 on: March 10, 2013, 07:01:28 PM »
Would you please explain more detail to do this procedure, I am trying to do that without succes I do not know what I am doing wrong! :(


I installed Smarterm, but I had to manually install the version 7 driver in the system32 folder and go through device manager to get the driver registered.  I could not get windows 7 to install the drivers due to them not being digitally signed and Galil does not support or recommend them for use with w7.  I've read through the Galil notes and verified all the needed drivers are now in my windows/system32/drivers directory.


Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #3 on: April 06, 2016, 06:40:28 PM »
Wow...  That is a weird one!

All the check box does is control whether or not to use a JG command or an OF to run the spindle.  It does no other magic.  

I assume that your spindle does not use an encoder.  If that is the case, then the KP, KI, and KD parameters for the axis driving the spindle all need to be set to 0 and burned with the BN command.  Otherwise, you need to have proper PID values to use an encoder.

Maybe your previous card had the PID set to zero and you new one doesn't.  That is the only thing I can come up with.  

Steve
Hello Steve, just a quick question, I have a Hardinge HNC lathe with a Galil 2130 running a VFD and have it working without the encoder, but how do I tune the (and get the P.I.D Values) so that I can use the encoder that I have on the spindle...it's a 2500 PPR quad encoder 1-1 on the spindle? The encoder is properly wired to the Y(B) axis that sends the 0-10v to the VFD also this encoder has index..does that help anything? hoping I can try threading!

-Roo Trimble...BTW: to see a lot of fun Mach-created widgits take a look at the little car that I bulit...www.roopod.com   Thanks in advance!

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #4 on: April 06, 2016, 07:28:21 PM »
Wow...  That is a weird one!

All the check box does is control whether or not to use a JG command or an OF to run the spindle.  It does no other magic. 

I assume that your spindle does not use an encoder.  If that is the case, then the KP, KI, and KD parameters for the axis driving the spindle all need to be set to 0 and burned with the BN command.  Otherwise, you need to have proper PID values to use an encoder.

Maybe your previous card had the PID set to zero and you new one doesn't.  That is the only thing I can come up with. 

Steve
Hello Steve, just a quick question, I have a Hardinge HNC lathe with a Galil 2130 running a VFD and have it working without the encoder, but how do I tune the (and get the P.I.D Values) so that I can use the encoder that I have on the spindle...it's a 2500 PPR quad encoder 1-1 on the spindle? The encoder is properly wired to the Y(B) axis that sends the 0-10v to the VFD also this encoder has index..does that help anything? hoping I can try threading!

-Roo Trimble...BTW: to see a lot of fun Mach-created widgits take a look at the little car that I bulit...www.roopod.com   Thanks in advance!


First, the VFD must be able to run like a servo drive.  In most cases, this means that it can accept a +-10v command signal AND allow disabling on its internal PID control loop.  This allows the Galil to run the control loop.  Then you set up the PID values in the Galil.  You cannot have two control loops running!  That is a PID fight.  Much worse than a cat fight.  :)  As to what values to use for PID in the Galil, that is very VFD/motor dependent.  And it is NOTHING like tuning a table load for a servo.  Galil has an application note that explains some of the peculiarities. 

If the VFD has a setup that shows the internal PID values, you can then use those to figure the ratios between P, I, and D, but the actual numbers will be different on the Galil.  If the VFD can't disable its own PID loop (very common, unfortunately), you are then stuck with the unenviable task of trying to match the PID loop on the VFD to the one on the Galil EXACTLY to avoid a PID fight.  Not easy to do.  But people get lucky sometimes...

Second, only Kenny has threading working on his lathe.  And it was a HUGE task.  Not for the feint of heart.  It evolves writing a Galil language routine that runs on the Galil, a modified 1076 macro, and Notifies setup to poke values down to the Galil.  The index pulse can be used to sync the thread.  However, it is just a blip on the radar and Kenny had to run that index pulse into a one shot timer to extend the signal beyond 4ms.  The output of the one shot timer is then wired to two GP inputs (the position latch inputs 1 and 3) to "start" the threading routine that is running on the Galil.  The Galil routine should be modified to reflect the counts per unit of the machine. 

The details and files required for this are here: http://www.smcomp.com/~smurph/exes/MachGalilThreading.zip.  However, you are on your own to get this working.  Kenny and I are too busy to provide any kind of support in this realm. 

Steve



Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #5 on: April 07, 2016, 03:45:55 PM »
 :)
Wow...  That is a weird one!

All the check box does is control whether or not to use a JG command or an OF to run the spindle.  It does no other magic.  

I assume that your spindle does not use an encoder.  If that is the case, then the KP, KI, and KD parameters for the axis driving the spindle all need to be set to 0 and burned with the BN command.  Otherwise, you need to have proper PID values to use an encoder.

Maybe your previous card had the PID set to zero and you new one doesn't.  That is the only thing I can come up with.  

Steve
Hello Steve, just a quick question, I have a Hardinge HNC lathe with a Galil 2130 running a VFD and have it working without the encoder, but how do I tune the (and get the P.I.D Values) so that I can use the encoder that I have on the spindle...it's a 2500 PPR quad encoder 1-1 on the spindle? The encoder is properly wired to the Y(B) axis that sends the 0-10v to the VFD also this encoder has index..does that help anything? hoping I can try threading!

-Roo Trimble...BTW: to see a lot of fun Mach-created widgits take a look at the little car that I bulit...www.roopod.com   Thanks in advance!


First, the VFD must be able to run like a servo drive.  In most cases, this means that it can accept a +-10v command signal AND allow disabling on its internal PID control loop.  This allows the Galil to run the control loop.  Then you set up the PID values in the Galil.  You cannot have two control loops running!  That is a PID fight.  Much worse than a cat fight.  :)  As to what values to use for PID in the Galil, that is very VFD/motor dependent.  And it is NOTHING like tuning a table load for a servo.  Galil has an application note that explains some of the peculiarities.  

If the VFD has a setup that shows the internal PID values, you can then use those to figure the ratios between P, I, and D, but the actual numbers will be different on the Galil.  If the VFD can't disable its own PID loop (very common, unfortunately), you are then stuck with the unenviable task of trying to match the PID loop on the VFD to the one on the Galil EXACTLY to avoid a PID fight.  Not easy to do.  But people get lucky sometimes...

Second, only Kenny has threading working on his lathe.  And it was a HUGE task.  Not for the feint of heart.  It evolves writing a Galil language routine that runs on the Galil, a modified 1076 macro, and Notifies setup to poke values down to the Galil.  The index pulse can be used to sync the thread.  However, it is just a blip on the radar and Kenny had to run that index pulse into a one shot timer to extend the signal beyond 4ms.  The output of the one shot timer is then wired to two GP inputs (the position latch inputs 1 and 3) to "start" the threading routine that is running on the Galil.  The Galil routine should be modified to reflect the counts per unit of the machine.  

The details and files required for this are here: http://www.smcomp.com/~smurph/exes/MachGalilThreading.zip.  However, you are on your own to get this working.  Kenny and I are too busy to provide any kind of support in this realm.  

Steve





Thanks So much Steve...Turns out my VFD only does 0-10V so till I get a dif one, I am threadless.  BUT I ran into a new problem...this since I upgraded my computer to a core2 duo running W7 ultimate.  and every time I start MACH3 It slows the computer way down (as in the reset button flashing very slow) and I get a ERROR message that says "Response from the controller was larger than the response buffer supplied"  I sort of fix this problem by going to WDSK and resetting the controller.  A new galil error then shows "variable error 9"  this stays and cant be cleared, but it seems like everything else is working...any thoughts?

So here are my questions:
1-Galil response buffer error?

2-how do I adjust the 0-10V offset so RPM matches VFD...(I can't get it to put put more than 5v..)

3-advice on controlling my Hardinge HNC turrret (galil program?) it has a 4-input encoder that shows turret position and 1 output to lift and turn and another to stop.  I have all the hardware hooked up and can see the encoder showing on my four galil inputs and if I am fast I can SB my output and grab the position I want...from what I understand this should be a DMC prog? but how does Mach3 tell it to change tools?

I understand you are busy and all...so anything you can offer is greatly appreciated!  BYW...if you need a BETA MACH4 galil plugin tester, I prob am game...

thanks,

-Roo Trimble
 :)
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #6 on: April 07, 2016, 06:30:14 PM »
:)
Wow...  That is a weird one!

All the check box does is control whether or not to use a JG command or an OF to run the spindle.  It does no other magic. 

I assume that your spindle does not use an encoder.  If that is the case, then the KP, KI, and KD parameters for the axis driving the spindle all need to be set to 0 and burned with the BN command.  Otherwise, you need to have proper PID values to use an encoder.

Maybe your previous card had the PID set to zero and you new one doesn't.  That is the only thing I can come up with. 

Steve
Hello Steve, just a quick question, I have a Hardinge HNC lathe with a Galil 2130 running a VFD and have it working without the encoder, but how do I tune the (and get the P.I.D Values) so that I can use the encoder that I have on the spindle...it's a 2500 PPR quad encoder 1-1 on the spindle? The encoder is properly wired to the Y(B) axis that sends the 0-10v to the VFD also this encoder has index..does that help anything? hoping I can try threading!

-Roo Trimble...BTW: to see a lot of fun Mach-created widgits take a look at the little car that I bulit...www.roopod.com   Thanks in advance!


First, the VFD must be able to run like a servo drive.  In most cases, this means that it can accept a +-10v command signal AND allow disabling on its internal PID control loop.  This allows the Galil to run the control loop.  Then you set up the PID values in the Galil.  You cannot have two control loops running!  That is a PID fight.  Much worse than a cat fight.  :)  As to what values to use for PID in the Galil, that is very VFD/motor dependent.  And it is NOTHING like tuning a table load for a servo.  Galil has an application note that explains some of the peculiarities. 

If the VFD has a setup that shows the internal PID values, you can then use those to figure the ratios between P, I, and D, but the actual numbers will be different on the Galil.  If the VFD can't disable its own PID loop (very common, unfortunately), you are then stuck with the unenviable task of trying to match the PID loop on the VFD to the one on the Galil EXACTLY to avoid a PID fight.  Not easy to do.  But people get lucky sometimes...

Second, only Kenny has threading working on his lathe.  And it was a HUGE task.  Not for the feint of heart.  It evolves writing a Galil language routine that runs on the Galil, a modified 1076 macro, and Notifies setup to poke values down to the Galil.  The index pulse can be used to sync the thread.  However, it is just a blip on the radar and Kenny had to run that index pulse into a one shot timer to extend the signal beyond 4ms.  The output of the one shot timer is then wired to two GP inputs (the position latch inputs 1 and 3) to "start" the threading routine that is running on the Galil.  The Galil routine should be modified to reflect the counts per unit of the machine. 

The details and files required for this are here: http://www.smcomp.com/~smurph/exes/MachGalilThreading.zip.  However, you are on your own to get this working.  Kenny and I are too busy to provide any kind of support in this realm. 

Steve





Thanks So much Steve...Turns out my VFD only does 0-10V so till I get a dif one, I am threadless.  BUT I ran into a new problem...this since I upgraded my computer to a core2 duo running W7 ultimate.  and every time I start MACH3 It slows the computer way down (as in the reset button flashing very slow) and I get a ERROR message that says "Response from the controller was larger than the response buffer supplied"  I sort of fix this problem by going to WDSK and resetting the controller.  A new galil error then shows "variable error 9"  this stays and cant be cleared, but it seems like everything else is working...any thoughts?

So here are my questions:
1-Galil response buffer error?

2-how do I adjust the 0-10V offset so RPM matches VFD...(I can't get it to put put more than 5v..)

3-advice on controlling my Hardinge HNC turrret (galil program?) it has a 4-input encoder that shows turret position and 1 output to lift and turn and another to stop.  I have all the hardware hooked up and can see the encoder showing on my four galil inputs and if I am fast I can SB my output and grab the position I want...from what I understand this should be a DMC prog? but how does Mach3 tell it to change tools?

I understand you are busy and all...so anything you can offer is greatly appreciated!  BYW...if you need a BETA MACH4 galil plugin tester, I prob am game...

thanks,

-Roo Trimble
 :)

Forgot to add this:
I Tried both versions of the Galil Plugin reg with Galil registered with galil tools, and ST registered with WSDK...same issue...

thanks again!

-roo

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #7 on: April 07, 2016, 10:35:42 PM »
Basically, that error suggests that the controller is not being fed information fast enough.  If your computer is running very slow, then that is going to be the cause.  So...  why is the computer running slow?  It may be that you installed the parallel port driver?  Maybe Mach 3 is trying to communicate with it?  I simply do not know what that might be.

Steve
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #8 on: April 11, 2016, 08:27:28 AM »
Basically, that error suggests that the controller is not being fed information fast enough.  If your computer is running very slow, then that is going to be the cause.  So...  why is the computer running slow?  It may be that you installed the parallel port driver?  Maybe Mach 3 is trying to communicate with it?  I simply do not know what that might be.

Steve

Just in case you get a chance: here is the Galil Debug file...if it helps anything??
Thanks!
the variable error starts after I got to Smartterm and reset the controller....
-roo
Re: Upgraded to win7 on PCI system - now weird VFD behavior
« Reply #9 on: April 11, 2016, 09:00:11 AM »
Basically, that error suggests that the controller is not being fed information fast enough.  If your computer is running very slow, then that is going to be the cause.  So...  why is the computer running slow?  It may be that you installed the parallel port driver?  Maybe Mach 3 is trying to communicate with it?  I simply do not know what that might be.

Steve

Just in case you get a chance: here is the Galil Debug file...if it helps anything??
Thanks!
the variable error starts after I got to Smartterm and reset the controller....
-roo

PASS on that...I just figured it out!  I had "Disable leading 0's communication parameter set to off...that was doing it...no errors now!
-roo  ps maybe the plugin should set that parameter on the controller...