Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: coyotegd on September 07, 2007, 07:12:45 PM

Title: Charge Pump Signal Hiccup
Post by: coyotegd on September 07, 2007, 07:12:45 PM
I've struggled with this for two days.  I know for a fact that Mach3's 12.5kHz charge pump signal is 12.1kHz, and it has such a bad hiccup every second or so, that a microprocessor counter routine to find the input frequency rejects the signal completely and executes code that's for a "no signal" condition.

I have a relay that stays on except for an off condition for a split second every second or so.  I know for a fact that the relay's off condition is caused by the hiccup in the charge pump signal.  I've confirmed this with a Function Generator emulating the charge pump's 12.1kHz.

Has anyone else encountered this, or do you have a work around?
Title: Re: Charge Pump Signal Hicup
Post by: Whacko on September 08, 2007, 05:32:46 PM
I don't think this topic wants to die. I have found this true with different motherboards, some have it some don't. I picked up on this when I used a PIC12F629 to do just that. The best is to work around it. To do a pulse to pulse monitor of the chargepump is in most cases not neccesary. The best way to make sure the chargepump is running, is by capacitive or inductive decoupling. It cannot fail unless a physical event destroys the hardware.

Whacko
Title: Re: Charge Pump Signal Hiccup
Post by: coyotegd on September 08, 2007, 06:51:57 PM
Sure the chargepump signal only needs to be something other than always high or always low periodically depending on whether it's active high or low.  However, when you are given information you believe is fact and design around it, you can run into very frustrating situations.  In one millisecond I should be able to count 12 to 13 transistions to or from high to low and visa versa with a 12.5kHz square wave signal.  My software code only believes Mach3 is up and running when it counts anything over 1 or 1000kHz.   I would say that is a significant error.  Shouldn't the Mach3 user's guide or whatever say that as long as you can measure a signal greater than 1000kHz Mach3 is running?  Really, if the frequency isn't important?

The first thing I thought about shortly after finding this signal hiccup was whether the stepper-motor signals will be just as dirty.  I can only hope that the compromise of a 12.5kHz signal was for a benefit in the signal clarity for stepper-motor control.

BTW, setting the chargepump for 5kHz operation for laser use results in a 2.6kHz signal that's just as dirty as the actual 12kHz chargepump signal.
Title: Re: Charge Pump Signal Hiccup
Post by: Whacko on September 09, 2007, 01:44:54 AM
You have to consider more causes than just Mach3. As I said before, it could be your system hardware, too little memory, threads running in the background, sloppy BIOS firmware, the list can go on and on. Software like Mach3 "asks" and "tries". It is the hardware and firmware that must give. Install Mach3 on another system, with minimum 512mb ram and no video sharing and check it again.

Whacko
Title: Re: Charge Pump Signal Hiccup
Post by: coyotegd on September 09, 2007, 02:05:05 PM
I am using WinXP, Pentium 4-3 GHz, 1 Gig of  RAM.  I bought this laptop solely for the purpose of CNC.  The only application software installed is MACH3.

BTW, a had to reduce the count to anything greater than 0 during a 1ms count of the charge pump.  With a setting of anything greater than 1, the PIC believed MACH3 was working, but this oscilated the PIC outputs when asked to go high.

I guess my point remains that the MACH3 setup, owner's manual or whatever should add a hugh qualification to the claimed 12.5kHz charge pump signal about exactly what we have discussed.
Title: Re: Charge Pump Signal Hiccup
Post by: Jeff_Birt on September 10, 2007, 09:54:15 AM
Laptops can be hideous with Mach III.  All the power saving systems can cause lots of timing issues.  When I first set Mach up for testing I was running on a Dell D610 laptop and it was nasty.  I found a post here, named something like, 'Running Mach on a laptop', that had a link to a piece of software that let you keep the processor running full speed.  That helped a bunch although I still had a hiccup which was tracked down to the bloody QT.exe (or what ever it's called) service the QuickTime installs that seem to have no other purpose than to eat up half your processor every couple of seconds.  I've since built a 'new' ( a few years old) computer, just for the controller, and it is working great.

Title: Re: Charge Pump Signal Hiccup
Post by: coyotegd on September 10, 2007, 01:47:25 PM
You can get a laptop to work just like a desktop if you know where all the laptop specific items are located and turn them off.  I did this because it's always plugged in to a wall socket.  I don't have any software installed other than system software necessary to run MACH3.  My toolbar only has icons for "network connection", "sound", and "safely remove hardware".

I'll test the 12.5kHz signal on my desktop sometime too.  I'll bet it's just as bad.

BTW, for as long as I can remember, a digital "enable signal" (for example, CE, "Chip Enable") is simply a low.  A few have high to enable, but no common chips like transceivers, multiplexers and demultiplexers use a square wave to enable.  Why not simply a low or high on the charge pump?

What's with the name "charge pump" anyway?  This sounds like some legacy language that goes back to a hydraulic triggering mechanism.  Why not "MACH3 Enabled" with a high or low?
Title: Re: Charge Pump Signal Hiccup
Post by: Jeff_Birt on September 10, 2007, 02:15:43 PM
First what does your driver test look like?  There are lots of things that can influence timing, drivers and running services can cause problems, not to mention the the design of the hardware itself can cause problems.  When your 'charge pump' signal is going wonky what do your step signal look like?

The term 'charge pump' comes from a circuit design that uses a free running oscillator to generate a different voltage (higher or negative).  In the case of Mach III the 'charge pump' signal is used as a watchdog signal.  Mach III HAS to be running properly for this signal to be present.  Parallel port pins will be in an unknown state when the PC starts and/or when Mach starts.  When Mach takes control of your LPT you don't it will reset all the proper state, in the mean time you do not want a LPT pin that is latched hi or low to falsely indicate to you machine that it is OK to move.

I'm not discounting that there may be a bug in the charge pump driver, I'm hoping Brian or Art will chime in on that.  But I think you need to do a bit more investigating to rule out problems with you OS/hardware first.
Title: Re: Charge Pump Signal Hiccup
Post by: coyotegd on September 10, 2007, 04:42:17 PM
Sure, dude, I'm using the charge pump for the reason you explained.  I don't want my steppers moving when I start my computer and made the mistake of powering up the motor drivers first.  I don't want to have to remember to 1. turn on the computer; 2. start Mach3; and 3. power up the drivers.

I have yet to control a stepper through Mach3.  I've have tested the drivers and motors with test equipment signals and power.  I'm still working on my breakout board.
Title: Re: Charge Pump Signal Hiccup
Post by: Whacko on September 10, 2007, 04:56:32 PM
Ah! Now I know why we can't tune in on the same wave lenght. The chargepump is as Jeff said, a watchdog signal. Unfortunately, if you do not control all the Parallel port signals, and at start up, the states of the pins is unknown, and with my breakout boards which has led indicators, I can see unvoluntary activety on the port pins on all PC setups I've seen. But having a signal at some khz is very unlikely to be coincidental uncontrolled port pin activety. I have worked with the Rofin Sinar lasers and Messer Griesheim CNC machines some years back when Messer Griesheim was still a good company to work for (sorry to folks at Messer) and believe me, a watchdog is necesary.
The best way and the only way I've seen industry specific implementation of the watchdog signal, was a constant frequency similar to Mach3 on a decoupled circuit. Mostly inductive decoupling. If you don't mind, how were you going to implement this signal?

Whacko

Addon:
I see you did answer that question, your post slipped by whilst I was typing mine.
Title: Re: Charge Pump Signal Hiccup
Post by: coyotegd on September 10, 2007, 05:15:05 PM
CNC is just a hobby for me.  It grew out of a hobby of computer programming in Visual Basic, which led to Programmable Integrated Circuits ("PIC") with PIC Basic.  PIC lingo has the term "watchdog" also, but there it's called a "watchdog timer".  I suppose it has something to do with synchronization, but I have yet to have a problem that is solved by a "watchdog", so I know very little about it.

I do know how to capture a signal on a PIC pin.  It would be much easier if it was simply an on or off.
Title: Re: Charge Pump Signal Hiccup
Post by: Whacko on September 10, 2007, 05:31:37 PM
PIC from Microchip is great stuff! I use a whole range of them in automation. I like the 16bit ones. How is your electronic knowledge? I can help you with the chargepump decoupled signal, or there is a different version in the "download" section of art's website.

Whacko
Title: Re: Charge Pump Signal Hiccup
Post by: coyotegd on September 10, 2007, 07:22:55 PM
I'm using a Microchip 16F877A.  I would say my electronics knowledge is as good as a Techenical College degree.  By decoupling the signal do you mean having a capacitor between the signal input and ground?

I didn't know there was a "decoupled signal" example in the downloads.
Title: Re: Charge Pump Signal Hiccup
Post by: Whacko on September 11, 2007, 01:51:29 PM
Yes, a capacitor arranged so that you have a charge pump circuit. Only a signal that changes rapidly will build up a charge good enough to switch a comparator. Inductive decoupling would be like a pulse transformer, again only a signal that changes state rapidly can cross the isolated barrier via magnetic flux variance in the transformer. You have to implement this through a current limiting resistor so that if the port state is active high, you will not damage the switching device, like a mosfet, or bipolar transistor.
The example in the download page is apparently good, but I have not used that one.

Whacko