Messages

451

General Mach Discussion / Re: probe guard

« on: May 05, 2014, 03:40:09 AM »

Hi Roger - at the moment I'm just wanting to gauge interest before I commit to spending more time (and money) developing it. Hardware and software solutions are how I earn my crust so it has to be worth my while. I doubt I'll be able to retire to Florida on it but hey... it's what I do.

At the moment it simply activates a TTL signal - and TBH I'm not sure what else it could do but if you have suggestions please feel free. I currently have that signal as a limit into Mach - simple as that. This of course allows you to TREAT it as a limit and jog back off it. You could of course add it into the E-Stop into Mach but I'm not sure how you'd get off it (without disabling it - and I'd like not to have to do that). Depending on your hardware you could also wire it into your hardware E-Stop - but again - getting off it might be an issue I suppose. Like I say - still under development.

Ian

452

General Mach Discussion / Re: probe guard

« on: May 04, 2014, 01:26:00 PM »

OK I am confused HOW is it to know wether it is a GOOD trip or a BAD trip. Do you turn it ON/OFF when needed like protected movemode on commercial controllers or

(;-) TP

It just knows  - no you don't need to do anything - you connect it and forget it - it just sits there and takes care of you.

453

General Mach Discussion / Re: Odd behavior with probe wiring

« on: May 04, 2014, 12:01:52 PM »

When the plate is connected to the input line, and the alligator is connected to the "power ground" on the breakout board, the circuit simply does not work, regardless of how I set Mach 3 input states.
tony

Saying the "the circuit simply does not work" is not the most helpful description of what's happening.

With the input connected to the plate and set in Mach to active LOW and doing NOTHING with the clip - is the input LED in Mach lit or un-lit?

454

General Mach Discussion / Re: Odd behavior with probe wiring

« on: May 04, 2014, 10:59:35 AM »

OK I remember seeing another post like this a while back. (http://www.machsupport.com/forum/index.php/topic,26294.0.html)

I don't know why people wire them like this - it's a really crap way to do it and MORE than likely to result in the effects you're seeing. Particularly the short which is VERY likely to damage something if it hasn't already.

You'd be FAR better off wiring the plate to your input pin and setting that input pin in Mach to active LOW. Then connect your clip to GROUND and clip it onto your tool. FORGET the 5V supply terminal - you're asking for trouble.

Now the plate will be sitting at the pull-up of the input and connecting it to ground with your clip/tool will signal an active low to Mach. No danger of shorts or anything else. The worst that can happen is you put the plate on a grounded surface and then it'll signal Mach - but that's all - it won't short anything out.

455

General Mach Discussion / Re: Odd behavior with probe wiring

« on: May 04, 2014, 10:00:52 AM »

It's a little confusing from your post exactly how you've wired what to what. For example in your post above you mention probe, plate, tool and clip.
You appear to have your PLATE connected to an input but what is connected to your CLIP.
Also please post the xml file you're using.

456

General Mach Discussion / Re: probe guard

« on: May 04, 2014, 07:24:18 AM »

Offcourse! Are you going to disable motor movement at breakout board ?

It provides a TTL logic output which you can connect to whatever you like. e.g. you could connect it into Mach e-stop or limit or you could connect it direct into your e-stop hardware - up to you really.

Sounds great, though not sure how a g31 can trigger a disable output whenever used.

Neat isn't it 

457

General Mach Discussion / probe guard

« on: May 04, 2014, 05:48:26 AM »

I've been working on and off for a while on a hardware gizmo for protecting ANY probe from getting crunched. It's currently bread-boarded and under test/development. Once OK - I'll go ahead and vero one but if there's sufficient interest I may have a batch of pro boards made up once it's completely tested.

Basically it's hardware that's added into the control box and then any move that is going to crunch the probe if not stopped will throw a limit (or e-stop).

It'll protect the probe during ANY and ALL types of move, jog, rapid, feed and EVEN (but of course) G31.

I'm aware there are some software attempts at this out there but IMHO they STILL depend on the control software (Mach/LinuxCNC, whatever) not doing anything bizarre. Because this is a hardware solution entirely independent of the control software it *should* be foolproof (that's where the work is at the moment - checking, checking and triple checking).

So - over to you - any interest?

Cheers

Ian

458

General Mach Discussion / Re: What happens when...

« on: May 02, 2014, 12:04:40 PM »

if THC is on then Mach will stop.

Re-starting a plasma job is not without its challenges - do a search on RFH (Run From Here) and see where it takes you.

If it's duty cycle kicking in that's your concern how about getting creative and get Mach to stop between cuts if it's about to run out of time, wait and then resume when it's got more money in the meter.

459

VB and the development of wizards / Re: File I/O being called out of order

« on: April 30, 2014, 05:35:43 AM »

All of my issues seem to boil down to one question.
How do I enable a “wait until line is finished” type of logic into movement and non-movement commands?

Scripts occupy their own thread - distinct from and concurrent with Mach. Your SCRIPT lines ARE being executed in the order you wrote them. HOWEVER, The things your script asked Mach and the OS to do don't necessarily get started or finished in that same order. It depends on how busy Mach and the OS are and how long it takes them to do the things your script asked them to do. This is the nature of concurrent systems.

What you're wanting to do is to BLOCK until Mach and the OS signal that the things you've asked to be done have "finished" before moving on to the next line of script.

You already know how to BLOCK for Mach's completion - use isMoving() as you did in sub1.

For OS calls, specifically Shell, the Cypress Basic implementation doesn't support blocking so you'll need to use the WSript version instead).

Use it like this:

Set objShell = CreateObject("WScript.Shell")   
objResult = objShell.Run("notepad.exe", 1, True)

This will BLOCK until you close Notepad.

Cheers

Ian

460

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

« on: April 29, 2014, 08:08:48 AM »

You are blowing my mind! Thank you so much! This could save me lots of time.

I thought from this post in 2010 that you had to put your parameters in a filename and then make a bunch of different files: http://www.machsupport.com/forum/index.php/topic,15179.0.html

well it's a way - no doubt about that... 

Is there a thread out there that discusses how to pass parameters through Gcode?

I think maybe you should have a read of the various programming docs here http://www.machsupport.com/help-learning/product-manuals

But parameters are pretty straightforward. You can have up to 3, namely P, Q and R. e.g. M1000 P7 will pass 7 into the macro. Then you retrieve them in the macro with the functions param1(), param2() and param3() so in this example (P) you'd retrieve it with param1().