Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: mTron on January 27, 2013, 02:28:46 PM
-
Hi
New to this forum I need your help in a strange problem I experience in my stepper-motor driven Quantum BF20L mill, controlled by Mach 3.043.022. The PC is an elderly Intel P5 machine running at 512MHz; it is dedicated to Mach3 and has no network connections.
At the very beginning of my work with Mach3, about 3 years ago, the motors just screeched and didn't move. It happened quite rarely, say once in an hour's operation and when doing a G0 rapid move under G-Code control. I never had the problem when jogging, even when using the shift-key. I then reduced the maximum speed on all axes from 1500 mm/min to 1200 and also reduced the ramp to now 60 mm/sec/sec. This seemed to cure the problem or at least reduced it to a tolerable frequency.
Recently the problem reoccurred for no apparent reason, several times in an hour. I further reduced speed and acceleration - no improvement. There seems to be a coincidence: Usually when jogging in Step-mode the speed is very low. After a number of jogging moves in both Cont- and Step-mode with and without shift-key (rapid jogging) the speed in step-mode suddenly equals the last feed speed, which may be much higher. I cannot reduce it unless I terminate and restart Mach3. I have never consciously experienced step-loss under G0 when step-jogging speed was low. It also seems to me that when there is step-loss under G0 the usual acceleration ramp has vanished, which would explain why the steppers cannot follow. However I couldn't really verify that.
I then downloaded and installed the newest version of Mach3.043.066 including its driver. It didn't cure my problem, but since then I have a couple of new problems: :'(
a) When I pause a G-code run run with the space-key I cannot restart the run, i.e. "Cycle Start <Alt-R>" doesn't work any more.
b) When I zero the X- and Y-axes using an edge-finder in the Offsets-screen Mach3 correctly observes its radius. But when I then manually do a "G0 X0 Y0" command via MDI it has forgotten all about the edge-finder offset - the zero position is not where it ought to be.
Then I scanned this forum, but couldn't find anything that helped so far.
Does anyone of you have an idea what I could do next? ???
Thanks in advance and cheers!
Peter
-
Attach your xml and I will see if there is a problem with your config. Regarding the first issue (motors stalling) could be your pulse width is too narrow, try increasing that or even putting in Sherline mode if your kernel is just 25KHz.
Oh and BTW a 512meg computer may be struggling with Mach.
Hood
-
Hi Hood
Thank you for your rapid and helpful reply.
Please find attached the current xml-file. As you will see, the pulse width is already at its maximum of 5 us. The kernel runs at 25 kHz as you suspected. During the installation I ran the DriverTest which showed "excellent" pulsing up to 65 Hz. This BTW confirmed to me that the computer was fast enough for the job - maybe that conclusion was a bit premature. Anyway I shall take my office computer to the workshop to see if the "screeching problem" disappears. However this must wait till the weekend, because my job keeps me too busy. :(
What is the Sherline mode? (I couldn't find that term in the documentation.)
Peter
-
Pulse width can be set as high as 15 if I recall correctly, even though it says 5 on motor tuning page.
Sherline mode makes the pulse half width, ie 40Us, that is why you can only use it at 25KHz.
Was the line flat in the driver test?
Hood
-
At the time I thought that the line in Driver Test was reasonably flat, but judge for yourself in the attachment. Comparing the details between the office PC with the workshop PC makes me hope for a clear improvement.
Regarding Sherline mode: How do I set it?
And regarding the other weirdies I encountered using Mach3.043.066: Would you suggest that I go back to 3.043.022?
Peter
-
You set sherline mode from Config menu then Ports and pins, its over to the right on the first page that pops up, the one where you set the kernel.
Your driver test isnt bad but its not great either, ideally you want a very flat line with almost no disturbances.
I found weird happenings with 066 and Turn, not seen any with Mill but maybe go back and see.
Hood
-
Found Sherline mode - cheers! :D
So I'll reinstall version 022 on my office computer, drag it to the workshop and give my project another try. As I said from next weekend onwards. I'll keep you posted. Thanks so far!
Peter
-
Ok no problem :)
Hood
-
I did as I said: Using Mach3.043.022 on an Intel Pentium 4, 3 GHz with 2.5 GB RAM the mill ran as the famous Swiss clockwork. The first stress test was
...
m98 p2 l50
...
o2
g0 x0 y0 z0
g0 x100 y100 z100
m99
It tested not only the program's parameters but also the stability of the power supplies. When this ran well I started the maching program which crashed at the beginning of this thread. OK, for safety reasons I milled lots of air, but from time to time I stopped the run to verify that the real coordinates matched those of the DROs. Well, I didn't wait some 5 hours till it came to the end, but within the first hour everthing was perfect.
So I went out and ordered a new/old workshop computer: a DELL Optiplex 755 2 x 2.33 GHz. I expect it to be delivered some time this week.
Again, many thank for your support which led to the solution of the mystery.
Cheers,
Peter
-
Hello
I am facing a similar behaviour.
Everything is normally running fine... and seems the problem appears (to loose steps) only if am loading large G-codes (over 10 MBytes), could this be a cause also ?
Thanks!
Sam
-
Turn off the toolpath view and see if it helps, it could be that the large file is loading your computer too much. You turn it off from a button on Diagnostics page, its just above the Reset button.
Hood
-
Thank you!
I will try and see, but I think you are right...the problems started when I was tring to make a 32MB toolpath.
Never experience this issue before, however I will try to break the code in 3 or 4 smaller parts to avoid this issue
-
Hi Hood
The Dell Optiplex 755 has arrived in the meantime. I installed Mach3.043.022 and ran a few tests. At first sight all seemed to be well. Then I heard a thump from the steppers when I hit a key on the keyboard. I call it the sound of a missed step. It doesn't happen every time but often enough to worry about. And not all keys in all circumstances do it, but the space key to pause a running program is especially bad. When I hit it during a rapid move (G0) ever so often the screech and the lost steps are back!
After a through investigation I found that both the charge pump and the stepper pulses are cut out for some 400 microseconds every time I hit a key. The charge pump monostable is dimensioned at 290 us so it briefly disconnects the stepper drive which makes for the thump when it comes back. Making the monostable less stringent wouldn't resolve the problem because during those 400 us no stepper pulses are coming from the PC anyway. It seems that this is enough for the steppers (running at 20 kHz = 1200 mm/min @ 1000 pulses/mm) to lose track. My suspicion is that Dell has a concurrency problem between USB events (keyboard) and the LPT output. Scanning this forum for "Dell Optiplex" I seem not to be the first one having problems.
Apart of that the PC seems to be amply fast enough: The Windows (XP) task manager never showed more than 3% CPU load when running a reasonably complex G-code. And the PC is very small, just 26 x 9 x 26 cm and fits nicely under the workbench. What a shame!
So it seems there are a couple of options:
- Buy another PC small enough for the workbench, e.g. one of the rare barebones with parallel port. But unless I can try that with Mach3 and the mill before actually buying it I risk another wasted expense.
- Buy a SmoothStepper Ethernet. Electrically elegant, but not from a packaging point of view: There is not enough space left for it in the control electronic box - so I need another box plus power supply plus cabling.
What do you think?
Peter
-
I know Dells have a reputation for being bad with Mach, obviously not all but more than other brands I would say.
I think personally I would go ESS simply for the reason that you really should be able to run with any computer and any OS whether it be 32 or 64bit.
You could possibly fit the ESS inside the computer case and just run a parallel port cable to your control box.
That way you get the power from the computer.
Hood
-
You wrote "personally I would go ESS". Yes, this has become my favorite, too. Be it then, order an ESS at Warp9. I'll keep you posted how I get along, once I'll receive it. Thanks so far :)
Peter
-
Well out of the options you had I would "personally go for" but on any new machines I am doing I am using the CS-Lab products as they are more suited to Industrial machines and wiring practices. Things like differential signalling and 24v I/O are much preferred for noise immunity.
Hood
-
Hm, just to avoid misunderstandings: My mill is nothing fancy (cf. attachment as a prototype with open gear), so I want to keep cost within reasonable limits. Less for cost reasons than for personal thrill I developed all of the control electrics and electronics in-house. So far I didn't experience much sorrow re. EMC and signal quality, but I know what you mean. therefore I shall have a look at CS-Lab. Thanks for the suggestion.
Peter
-
I had a brief look at CS-Lab's CSMIO IP-M. An impressive little box at a truly attractive price, indeed. If I started with a new CNC project this would be my favourite, too. But as things are my current system uses a slightly different approach: My hand control and the PC running Mach3 are connected to the stepper drivers via an electronic switch. If Mach3 is not running or the PC is off,I can control the mill directly using the hand control. That's how everything started. That's how I started machining the prototype drive gear. When I run Mach3, the hand control is ineffective and I use the jog functionality of Mach3.
Current CNC practice runs the hand control (MPG) through Mach3. In that context CSMIO IP-M exactly fills the bill. But I am glad that you directed my attention to CS-Labs. Whenever I should decide that my manual lathe might make good use of CNC... ;)
Peter
-
The ESS is a great board, only thing is if wanting to integrate it into an industrial machine you need to do a lot of converting of signal voltages and you still need breakout boards, analogue I/O boards, Differential drivers and spindle control boards where the CSMIO boards all have that so its better for me.
If using 5v then as long as you are careful with correctly shielding the 5v signals all should be fine.
Hood
-
Another status report seems due: I bought an ESS from a local Swiss representative. Taking it into operation was a walk in the park. Everything seemed to work at first go. During my further tests I noticed a strange behaviour when holding the feed (Space-bar) while running a G-Code:
- When I leave the control of feed-hold to Mach3 there is more than 2 seconds delay after hitting the space-bar until the feed actually stops. The same delay applies when I resume operation (<Alt>-R). This seems awful long to me, although the operation is precise, i.e. clean ramping down and no lost steps.
- When I leave the control of feed-hold to ESS, the response is immediate with clean ramping down and no lost steps. However resuming operation behaves strangely: Motion starts immediately after <Alt>-R, but briefly pauses after about a second. If I pause and resume a second time within that 1 second time span, the feed (or rapid) motion briefly pauses twice. Again, no steps seem to get lost, but these pauses are not very confidence-inspiring to me.
Do you know these phenomena? Did I do something wrong e.g. in configuration? Are there any known workarounds? (Just as a reminder: I am using Mach3.043.022, because the most recent version did not want to restart after a feed hold...)
Thanks for your ideas