Messages

411

Modbus / Re: How to Address Modbus Outputs if you have more than 20

« on: September 02, 2014, 07:13:38 AM »

BOBs are plentiful - might want to ask on the general forum - I don't use them so can't offer suggestions.

If you want to use a laptop with Mach then your only real option is to use external motion control - again there are several - might want to google or ask on the general forum. Don't use one so I can't advise.

Personally I wouldn't use threaded rod for "lead screws". Apart from not being very accurate, the pitch is way too low for a router.

412

Modbus / Re: How to Address Modbus Outputs if you have more than 20

« on: September 02, 2014, 06:10:39 AM »

First step, just get your axes moving: All you need is Mach3 on a 32 bit windoze PC -> parallel port -> (optional BOB) -> drivers -> motors (plus a power supply of course). See http://www.machsupport.com/help-learning manuals, videos etc.

(I've said BOB is optional but probably advisable unless you know exactly what you're doing).

413

Modbus / Re: How to Address Modbus Outputs if you have more than 20

« on: September 02, 2014, 04:08:22 AM »

I think you misunderstand what Modbus is for. It is for non-time-critical I/O expansion - you can't drive axis motion via Modbus.

With Mach you either use the Parallel port driver OR you use an external motion controller.

Arduino can be used with Mach for all sorts of things - but NOT for driving the axis (unless I suppose you write your own plugin which is non-trivial. Even then I'd argue an 8 bit processor is a poor choice for motion control).

414

General Mach Discussion / Re: Possible Mach3 G-code interpreter error

« on: August 22, 2014, 05:29:45 AM »

FWIW you can reproduce the problem with this simplified code:

G64
F500
G1 X0.1
G1 A0.1 F500
G0 X0.2
M30

When this runs, the pulse stream for the rapid (G0 X0.2) is missing its accel ramp (which is why you get no movement and just a buzz). As an added bonus, CV fails to blend the two feed moves (G1) correctly. (The in-line feed causes a delay between the two moves).

However if you take out the F500 off the A move - it all works as you'd expect. (No delay AND you get a properly formed accel ramp on the rapid).

Alternatively you can run it in exact stop (G61) WITH the inline F500 and then the G0 DOES have an accel ramp. (but of course you loose blending).

The problem is a combination of CV, A moves (both rotary and linear) and in-line feeds.

Incidentally - replacing A with Y in the code above, in-line feeds still kill CV even between X and Y. I've never spotted this before because I've never had the need to change XY feed in-line.

It's not productive to fix Mach3 since it has limited lifetime anyway now that Mach4 is here.

It's actually the other way round.

Mach4 "is here" because it wasn't deemed productive to fix Mach3.

415

General Mach Discussion / Re: 1st pierce is longer...

« on: August 20, 2014, 05:24:58 AM »

This seems to be related...
http://www.machsupport.com/forum/index.php?topic=17435.5;wap2

Not just related - it seems to me to pretty much cover your issue.

I looked through the Proma leaflet, and it clearly states that NO output will be energised when only the pilot-arc is struck i.e. firing in air.

So i threw in some used consumables, switched to the diag page in Mach and fired the torch in air, sure enough I was getting an Arc-Ok signal, this is WRONG and possibly what is messing up Mach3.

As you say - this is incorrect behaviour of your THC. I can only suggest you take this up with Proma.

So I noted the voltage displayed when the torch was firing in air (150v) and turned the HV setting in the Proma box down to 140v. This is higher than my highest cutting voltage BUT lower than the pilot voltage as I presume this is how Proma detects Arc-Ok.

Ark-OK should be established by a THC when CURRENT is detected in the CUTTING arc as opposed to current in the pilot arc. i.e. when the pilot arc actually transfers to a cutting arc.

But now when I try to run code, the arc will fire but as the torch pierces quickly on the 1.5mm test sheet, it then reverts to a pilot arc before Mach has time to drop the torch to cut height and start moving.

This is to be expected. It is not so much the cause of your problems but a symptom of them. Once you have pierced the system MUST start cutting otherwise the arc will start to deviate to find the edge of the pierce hole. Eventually it will not be able to deviate far enough as it widens the hole and will therefore not be conductive. Current ceases and so the torch flips back to pilot. The hole is now too wide to allow transfer so the pilot will remain until timeout.

EDIT: you just posted at the same time - but I'd written it so I'll leave it for your interest.

416

Promote and discuss your product / Re: Neuron.THC Torch Height Control (plasma)

« on: August 18, 2014, 05:27:14 AM »

Documents! - where would the fun be? 

417

Promote and discuss your product / Re: Neuron.THC Torch Height Control (plasma)

« on: August 17, 2014, 08:53:59 AM »

but I mean that the poll  of the input signals (THCUP and THCDOWN from the most Torch Height Control system) is 1/10 of a second or from plugin (from 100 msec to 25 msec).

Hi

yes I know what you mean - but as I've said - I disagree. Please see attached logic analyser scans.

Scan1.jpg is of a test function of my THC. It's simply toggling the UP/DOWN signals to Mach every 1ms i.e at 1KHz. This is a plain vanilla Mach running the parallel port. You can see that Mach correctly responds to each and every UP/DOWN signal by toggling the DIR pin and sending a step pulse - i.e. it's doing this at 1KHz - in perfect sync with the THC. Not something it could do - I hope you agree - if Mach was just polling at 10Hz.

In the second scan I've upped the rate to 2KHz to match your 500 microseconds THC loop. Again - Mach keeps in step with it no problem.

This is not in any way to dis your THC. However I think it is wrong to state as you have both here and on your web page that...

Servo cycle is 500 microseconds, it is 200 times faster than the internal logic of the THC Mach3.

...because as I hope I've shown - it is not true.

418

General Mach Discussion / Re: 1st pierce is longer...

« on: August 15, 2014, 10:48:05 AM »

Running your code here, the time between the M3 activating and the M5 deactivating is:

1.73 sec using doSpinCW and doSpinStop and 0.32 sec using activate/deativate.

419

General Mach Discussion / Re: 1st pierce is longer...

« on: August 15, 2014, 09:19:25 AM »

Is it just a matter of changing the macro's to this style --- ActivateSignal(Output1) & DeActivateSignal(Output1) ?

You got it.

420

Mach4 General Discussion / Re: Mach4 Printer Port Discussions

« on: August 15, 2014, 08:35:01 AM »

Mach3 moved off, but it didnt accelerate, it just moved off at full set homing speed. This means a few steps "could" have gotten lost by the "auto move to zero" process. It didnt accelerate because it was the driver doing it, and it wasnt smart enough to know how to properly accelerate, though it tried.

Art

That "though it tried" has me intrigued.

I've always been of the understanding that Mach3 hits the switch decelerates to a stop, (reverses direction), accelerates, comes off the switch and then decelerates to a stop and calls that home.

I just scoped it here and sure enough that's certainly what it looks like - clear accel/decel ramps.

I then compared these homing ramp pulse timings to those used for jogging and they're pretty darn close - fractions of ms different.

Certainly here - "though it tried" translates to "and it darn well succeeds too". 

Ian