Messages

71

General Mach Discussion / Re: Limit Switch Request

« on: October 31, 2006, 01:52:00 PM »

Hi,
I am using version 2.0 as of about a week ago. I am using new mechanical snap action microswitches with an 8 oz activating force.  The software has a debounce function in it accepting a number times 40 microseconds. I started with 25 (1 millisecond) and then went to 50 (2 ms).  I have a strong electronics background and understand its purpose, and I do not want to delay more than 10ms before tripping. These switches should be very reliable at 1 ms debounce, providing the debounce algorithm is good. Unfortunately, all of the switches are mounted on mobile surfaces. Both Y and Z should be impervious to shock and vibration because of their orientation with respect to their activating axis and sources of vibration. X is mounted with a worst case orientation and is located near the screw where acceleration would be maximized. I will look here first. I operate using the constant velocity mode and was running this job at 40IPM cutting wood with a 3/32 bit

I ran a small number of jobs without also using the switches as homing switches. When I enabled homing and limit to the same switches, troubles seemed to begin. It is possible that the other jobs did not have as many hard turns in it. As I said before, I have not had a chance to test the capacitors I have added, nor have I reverted to eliminating the homing function.

The attachments should show that the setup is pretty mundane.
If the software were to indicate which switch tripped, then I could validate my theory about switch X.

Capacitors should cut down a lot of motor noise, but I think if motor noise was the culprit, that the switches, depending on the debounce algorithm, may never trip because the debounce circuit might never validate.

72

General Mach Discussion / Limit Switch Request

« on: October 31, 2006, 10:53:44 AM »

I recently installed limit switches on my table. They seemed to work just fine until I included them as a part of the homing limits. One of them keeps tripping during a job (according to the status report), well away from the limits. It is usually unrelated to large or particularly fast motion, so it is probably noise. I bumped up the debounce from 1 to 2 milliseconds, and it still trips about as often. I could probably safely go to 10ms on the debounce, but I wonder if that will help. I installed 0.1 UF caps on them but have not tested them yet.

Program change suggestion:
It would be nice if the program status indicated which limit switch tripped, so I had a starting place to look, or if there was any consistency involved.
It would also be nice if the reports indicated which line of G-Code was being executed when it tripped.

Any ideas?
Thanks.
Bill

73

General Mach Discussion / Re: run amuck on STOP

« on: October 27, 2006, 01:53:37 PM »

I can't say for sure if it has done it on the first time or not, but I believe it has. Except for the example below, I always try to rewind to a predictable X, Y, & Z starting point, and for the most part, it will start on track to the proper location. Each time the stop event has happened, the head was traveling along the desired path. It is just that hitting stop does more than raise and stop. Both X and Y are getting new values that are not on the path.

Even in the example below, after a successful stop, Start would harmlessly cause the tool to circle around at the safe height and in the correct location, and then with the next DOC iteration, plunge to the next cutting level and continue cutting the circles in the proper location. Because I was cutting air, I didn't violate any DOC rules that would have broken bits on a real job, so I didn't worry about finding a safe starting point. The point is that the tool was always on a valid path at the time a STOP was pressed.

All of the things you are saying are true, I probably shouldn't use STOP the way I do, and the risk of screwing up the job may increase as a result, however with that said, Stop MUST NOT pick up bogi X, Y, & Z values no matter how improperly anyone uses Stop. The meaning of STOP shouldn't change no matter how many times it has been used before.

I have been writing control code for many years and I have learned that a predictable response to an input is paramount. The STOP event smacks of nested interrupts clobbering registers. Preemptive interrupts, like STOP, are especially difficult to write because we tend to allow them to execute at critically bad times in the code (like when the registers are being updated).

Whatever the problem is, you will eventually find it, as I have often said, "hidden under a rock".

74

General Mach Discussion / Re: run amuck on STOP

« on: October 26, 2006, 11:15:46 AM »

Brian,
The problem is fairly easy to reproduce with the file. Since, during a test, I am not cutting any real material and the movement is not large, it is pretty safe to do live, and I watch the motion of the head. The pattern cuts several shallow holes using multiple passes for each hole. I don't press ESCAPE or FEED-HOLD in this procedure. I am currently using a touch screen to press the buttons, but have observed this problem using a PS2 mouse. I do not have a hardware START and STOP.

1) I load the G-Code, zero X, Y, & Z near the center of the table, touch REWIND, touch GOTO-Z, and touch START
2) I then wait until cutting a circle and touch STOP (on the screen)
3) if the error is not observed, I press START (I don't bother restarting the motor or repositioning anything) and then repeat step 2. 

I was able to get it to fail about one of every four tries, and never had to let it go on to the second hole.
The PC is a 500MHz 1999 vintage machine running XP-home. My 1.8GHz laptop was able to do the same thing.
I am running Mach3 2.0.1i on both.
Thanks.
Bill

75

General Mach Discussion / Re: run amuck on STOP

« on: October 25, 2006, 12:08:15 AM »

My primary concern is not losing steps, it is moving the bit to a safe height and stopping the motor (I can always back up to a predictable starting point). Problem is that the motor does not always go to a safe height and regularly moves to an unpredictable(??) x and y position, which I consider very dangerous (not to mention it breaks tools). I have a second file that while drilling the first hole will gump to X0.3635 Y0.2500 and Z0.000 on about every 4th stop. This position is not a safe directly above the hole (safe is set to 0.25 inch). Interestingly enough, the bad position is always the same for this file. And it looks like Y got the safe height value instead of Z, and It looks as though X got Y's value.

Thanks.
Bill

76

General Mach Discussion / Single line text in DXF format

« on: October 24, 2006, 03:43:50 PM »

I have been looking for a low cost (preferably free), single line, text generator that will support Ariel and other uniform thickness smooth fonts. It needs to be able to be ported into AutoCAD so I can size and position it with the cutout that it is to accompany. DeskEngraver seems to come close but it does not produce a DXF that AutoCAD 2005 can read (reports a file configuration error).

I want to be able to create custom shaped engraved faceplates/info-plates using a ball-nosed or V-nosed bit for the text. This is effectively 2D work with the text and pattern each on a different layer.

What would be really nice is if LazyCam would allow translating text direct from the DXF drawing file, However, I think that may be a bit much to ask.

Are there any good ideas out there for solving this problem?

Thanks.

Bill

77

General Mach Discussion / Re: Memory leak in Mach3 ver 2.0

« on: October 21, 2006, 10:20:28 PM »

I never actually ran a cut with it. I only needed to have the motor drivers energized. I did manually move the head several times. It mostly crashed while it was just sitting there idle with Mach3 on the screen. It is possible the PC is messed up, and is sensitive to noise on the parallel port. I have Mach3 now on another machine (older & slower) that seems to be doing fine (except in the presence of a USB wireless module).

78

General Mach Discussion / Re: run amuck on STOP

« on: October 21, 2006, 09:41:39 PM »

This is a play/learning file, and I was engraving (v-bit) in scrap material. This is approximately the same file except that the DOC was 0.075. It was cutting the last inside letter loops when I aborted the cut by pressing stop. The bit took off for about X6 and Y0.  I couldn't tell if Z moved first to the fast plane or moved with X and Y. I just noticed that there are almost no curves in it, just lots of quick vector changes. I wonder if one interrupt is interferring with another.
Good luck.
Bill

79

General Mach Discussion / run amuck on STOP

« on: October 21, 2006, 12:11:31 AM »

On several occasions, I have noticed that the CNC will move to some random position when I push the stop button.  A few of the times it did not lift the bit to the safe travel height and broke the bit. I have not seen the "Feed Hold" do this, and whenever I do a feed hold first, the stop acts correctly. I feel that this only happens while cutting an arc or circle. Today, it lifted the bit and moved the Z-axis to the positive limit, and Y-axis went to zero. I don't know to reliably repeat this effect. It is not unique to the current version.

Any ideas?

80

General Mach Discussion / Memory leak in Mach3 ver 2.0

« on: October 19, 2006, 05:32:29 PM »

Did that memory leak you fixed cause the program to crash regularly? I loaded the first 2.0 release and it crashed every few minutes to a full reboot.  It is on an unproven PC, so it could be that too. I loaded the latest (today) on a second PC and problem is gone.
Thanks.
Bill