Messages

1

General Mach Discussion / Re: Skipping movements intermettently, & work offsets

« on: September 29, 2011, 07:10:24 PM »

I had another play with the engraver today, and managed to produce enough good parts to keep the customer happy. I also ran the B programme repeatedly with no cutter, and the B in the graphics panel zoomed up to nearly full screen. Unlike yesterday the system now recognises the M3 command - but I changed absolutely nothing! First run, no problem. Second run the B went wrong in exactly the same way as before, and the wrong path was shown on the screen. So it must be a programme fault which is occurring in the sequencing of moves before the moves are issued for action. I imagine there is some kind of look ahead which is losing track of where it is in the list. On the third run the last G0 back to 0,0,0 got missed. This was very obvious even without taking a cut, and again showed on screen. When I homed the machine it hit the end stops again.

I ran the programme another twenty or so times to see if I could note more information from all the coordinates on the Diagnostics screen, or get a screen grab of the wrong path, but it refused to go wrong again. I then did about fifteen production runs with my long rotary programme with no errors (which gets the current production done plus spares for the future).

So I'm quite sure the error is happening in the programme, not the drive electronics, but I can't reproduce the fault reliably.

I'm unlikely to return to this for some days now as I have other projects in need of attention, but if anyone can suggest further experiments to help with diagnosis I will try to run them.

2

General Mach Discussion / Re: Skipping movements intermettently, & work offsets

« on: September 28, 2011, 06:49:05 PM »

I had about an hour this afternoon to play with the machine, and came away even more puzzled. I intended to run the B programme repeatedly to see if I could spot something when it glitched. However, today it gets stuck at the M3 command. It acts like it doesn't know what to do with it. The first G0 happens, then it stops without executing the M3 at the end of the line. Hitting the Start button continues the sequence but the cutter isn't running. Trying the machine with my Rotary profile everything runs normally, so it's not the interface or other electronics. I might try to configure the Mill profile, and see if that works better.

I can't see anything in the configuration to inhibit the motor other than the output allocation, and that is the same in both, as read from the Ports and Pins menu.

One thing I notice is that looking at the diagnostics page with the Rotary profile I can get the Current Position, Machine Coord, Work Offset, G92 Offset and Tool Offset to be all zero by homing the axes (G28.1 etc) With my XYZ profile that is impossible, and I think this is something to do with the problem. I reckon it's why the Y axis hits the end stop when homing, and may be to do with the error. I had this problem before and somehow managed to set everything to zero, but I can't see how to do it again.

I've attached a picture of the two faulty Bs, and I reckon the faults are identical. This surely rules out missing steps. For measurement purposes the character height is supposed to be 7 mm, but is a bit less, and the scan is at 1200 dpi. In the runs I did I didn't see any sudden changes in all the various coordinates shown in the Diagnostics page.

One thing to note is that the fault occurs whilst simultaneously scaling the X & Y axes, and in a subroutine. From other reading it seems that either is big trouble if the offsets decide to change while they are in force, but I may have misunderstood. I can cut and paste the single letter programmes to do away with the subroutine, but not the scaling, in the hope that will help.

I am considering two other possibilities. One is to reload Mach3 but keep my profiles and screens and see if that helps. I'm also wondering about viruses. This machine is stand alone so any anti-virus on it is totally out of date. I transfer files with a USB stick from my computer, and a recent virus scan said "3 trojans found". I tried to find out what they were, what had been done with them, when they had appeared, and so on, but there is no further information. It may be that they, or something, have got into the computer and are now doing damage. I need to find a way to keep the anti-virus up to date without connecting to the internet, thus avoiding the major source of viruses!

Does any of this get us further forward?

3

General Mach Discussion / Re: Skipping movements intermettently, & work offsets

« on: September 28, 2011, 08:34:22 AM »

Well, the problem with the Bs has only happened twice out of four attempts, but yes, it was the same both times. That's as judged by two skilled pairs of eyes, not measured. The other fault occurred on the same rapid move both times, the first time losing the Y, the second time losing X,Y & Z. I will have to look closely to see what happens to the DROs. I want to run the B cycle whilst watching the screen, not the cutter, but I can't get to the engraver at the moment. At least I can cut fresh air instead of wasting components.

4

General Mach Discussion / Re: Skipping movements intermettently, & work offsets

« on: September 28, 2011, 08:06:04 AM »

Yes, it's all on steppers, with no form of feedback. The acceleration profiles have worked well before, and the speed is not high - I haven't got around to speeding the machine up yet.

I've seen missing or added steps before, and they give a random result. I'm suspicious of Mach3 because this fault misses movements. Writing the letter B the first arc is not completed, with the same result two times, which would not happen just by chance, and no fault two times. In the second example one or more components - X, Y, or Z of a rapid command were missed. This is not the same as a few steps.

When i get back to the machine I will try repeated Bs to see if there is a pattern. I think the graphic screen was showing a discrepancy too, which would definitely be the programme, but when I zoom in on it to get the detail, the cut path vanishes. I must start with the image zoomed, and see what happens.

When I start up on one profile the machine zero is at the machine home, but on the second profile, made from the first with mods for three axes instead of four, the machine zero is different and the Y axis, which was not changed, hits the end stop when zeroing, which it never did before.

It's all very puzzling, and the parts are due out tomorrow!

5

General Mach Discussion / Re: Skipping movements intermettently, & work offsets

« on: September 27, 2011, 11:03:30 PM »

Thanks for looking and testing. I reckon the code is OK as I'm running batches of parts and using the subroutines in different orders for the various names and descriptions that get engraved. So the letter B  has only given problems in the first example although it is called up in the second one.

As for the zeroes, in one setup the G28.1 zeroes everything, which is what I need. The components are in a single fixture and it is essential that the home position is the programme zero. There is no other datum. So why does G54 have these residual values? I never put them there, and with a different profile on the same machine they are all zero. (I run different profiles depending on whether the machine is running a rotary job or working on the flat.)

It wouldn't matter too much but after months of experiment and discussion the salesman has gone mad and the orders are coming in, and now the problems show up, and I'm busy on other projects. So everything's quite normal!

6

General Mach Discussion / Skipping movements intermettently, & work offsets

« on: September 27, 2011, 05:22:38 PM »

When engraving identification letters on various components the machine is sometimes missing part of the movements, giving rise to various problems. Here is the latest programme to give problems:

G90
G0  X121.0 Y-75.0 Z0.0 M3
    Z-32.5
F   200
G91
G0  x -1.75
G51 X0.7 Y0.7
M98 P066

G50
G90
G0  Z0.0
G0  X0.0 Y0.0 Z0.0
M30

O066  (upper case B)
G91
G0  Y0.500
G1  Z-2.00
    X2.50
G3  X0.00 Y4.00  I0.00 J2.00
G1  X-2.5
    Y-9.00
    X2.50
G3  X0.00 Y5.00 I0.00 J2.50
G0  Z2.00
    X5.50 Y-0.5
M99

The sub-routine is from a library of alphabetic characters used with different engraving jobs. The G51 scales it from 10 mm high to 7 mm.

The B starts with the middle bar, then the upper curve, horizontal to the left, down the main upright, horizontally across the base then up with the lower curve to complete the letter in one continuous cut.

Today, two times out of four, the first curve of the B was not completed so the remaining lines were out of position, maybe 1.5 mm right and 0.5 mm down, so the upright is displaced to the right and the end of the line does not meet the middle bar as it should. This has wrecked the job at the last operation, which is very annoying.

At an earlier stage in developing the interface to this machine I got crosstalk between the watchdog signal and the X axis drive in a short section of ribbon cable used to extend the parallel cable into the machine. This gave rise to un-programmed moves on the X axis. Getting rid of the ribbon cable and taking the printer lead direct to the interface board seems to have solved that one, but it might be relevant. I still suspect the quality of printer cables when used for machine control.

Another programme on the same machine but using a different setup profile resulted on one occasion in the last character being out of position, showing that one rapid move had missed the X Y moves, and a second time the last character was overwritten on the second last, and the cutter dug in deep indicating an entire rapid move had been missed. Programme (without all the subroutines) below:

G90
G0  X1.0 Y-75.0 Z0.0 A-121.0 M3
    Z-32.5
F   200
G91
G0  Y2.50
G51 X0.3 Y0.3
M98 P050
M98 P046
M98 P048
M98 P032
M98 P109
M98 P109
M98 P032
M98 P083
M98 P084
M98 P065
M98 P073
M98 P078
M98 P076
M98 P069
M98 P083
M98 P083
M98 P032
M98 P083
M98 P084
M98 P069
M98 P069
M98 P076
M98 P032
M98 P040
M98 P051
M98 P049
M98 P054
M98 P041
M98 P032
M98 P067
M98 P069
M98 P082
M98 P084
M98 P046
M98 P032
M98 P050
M98 P056
M98 P051
M98 P051
M98 P052
M98 P054



G90
G50

G0  X0.0 Y-78.0 Z0.0 A-121.0
    Z-32.5
G91
G51 X0.3 Y0.30
M98 P083
M98 P078
M98 P066
M98 P032
M98 P069
M98 P108
M98 P101
M98 P099
M98 P116
M98 P114
M98 P111
M98 P110
M98 P105
M98 P099
M98 P032
M98 P083
M98 P101
M98 P114
M98 P118
M98 P105
M98 P099
M98 P101
M98 P115
M98 P032
M98 P050
M98 P052
M98 P072
M98 P114
M98 P032
M98 P084
M98 P101
M98 P108
M98 P032
M98 P048
M98 P055
M98 P055
M98 P049
M98 P048
M98 P056
M98 P052
M98 P048
M98 P051
M98 P054
M98 P049


G50
G90
G0  Z0.0
G0  X0.0 Y0.0 Z0.0
M30

O049  (numeral 1)
G91
G0  Y2.50
G1  Z-2.0
    X2.00 Y2.00
    Y-9.0
G0  Z2.00
    X5.00 Y4.50
M99

O054  (numeral 6)
G91
G0  X3.00 Y4.50
G1  Z-2.0
G3  X-3.0 Y-4.0 I1.1667 J-4.0
G1  Y-3.0
G3  X4.00 Y0.00 I2.00 J0.00
G1  Y1.25
G3  X-1.75 Y1.75 I-1.75 J0.00
G1  X-2.25
G0  Z2.0
    X7.00 Y-0.5
M99

Two lines of text are written using X Y scaling to set the character height, with a non-scaled move between lines to set the line spacing and centring.

I've only included the last two character subs - 61 - as that's where the problems occurred. Most of the subs have been used successfully in various combinations, so I don't think there is anything wrong with them in principle, although one or two may have errors in them. I would say the last G0 in sub 049 was being missed.

The only hint I can find, and it may not be relevant, is that I can't get the axes to zero when I issue G28.1. The initialising code at switch on is G28.1 X0 Y0 Z0 A0. This usually leaves X at 3.44, Y at 2.55, not at zero. If I look at the offsets, G54 Is also at X 3.44, Y at 2.55. If I zero them in G54, then the Machine Coordinates change from all zero to X3.44, Y 2.55. If I zero the machine coordinates the values reappear in the G54 offsets.

How do I, once and for all, make all coordinates zero when the machine has homed and (officially) zeroed all axes? My suspicion is that this discrepancy is giving rise to movement errors, but I can't prove it.

The computer is a VIA ITX running windows XP, configured by Les Caine as "Mach in a box", using Mach R3.042.020, and with his interface card. Motor drivers are IM483.

Can anyone shed any light on the missing movements, the zeroing problem, and any possible link between them?

7

G-Code, CAD, and CAM discussions / Re: G73 parameters

« on: November 05, 2010, 01:41:28 AM »

Thank you for that clarification. I have read the manual repeatedly, but it is clear that the discussion of G81 to G89 does not include G73, so it is not certain that the parameters described there also apply to G73. Previous versions of G73 I have used had a clear explanation but used different parameter letters.

Your second example in incremental mode is almost the entire programme for the machine I'm designing!

Thanks for the quick response.

8

G-Code, CAD, and CAM discussions / G73 parameters

« on: November 04, 2010, 08:15:52 PM »

I'm trying to use G73 for a row of deep drilled holes, and I can't see any guidance in the manual for the use of the parameters. I gather from other discussions that X & Y are the start position, that Z is the hole depth, R is the final retract position (maybe), L is the number of repeats (only useful in incremental mode) and Q is the retract increment. So what do A, B & C do? And have I got ANY of them right?

In other discussions F is brought in as a feed rate, but it's not mentioned in the G73 description. If F is a valid parameter for G73 shouldn't it be mentioned along with the others?

Can anyone clarify what the parameters are? Simple examples in absolute and incremental modes would be useful.

And if you did the same for the other canned cycles I suspect you'd be doing everyone a favour!


Keith

(not involved in previous G73 discussions)

9

Feature Requests / Re: Easy G-Code Scaling

« on: June 30, 2010, 11:50:43 AM »

Or use G51, but note that arcs specified in Radius format do not scale correctly, and you can"t scale the X & Y axes differently to produce an ellipse (I haven't tried that one to see what it does do!)

10

Mach Screens / Re: FRO Slider

« on: June 29, 2010, 08:07:36 PM »

Thanks for the quick response.

Mach3screen allows the FRO slider to be created as a type of DRO. I tried it in Machscreen, but with the same result. I haven't tried Screen4 as everything I had read here suggested it didn't really work. Did I get the wrong impression or has it changed?

It does seem to me that regardless of how you generate it, the slider still looks the same. There must be a hidden variable in there somewhere!