Hello Guest it is April 19, 2024, 02:30:24 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - stirling

1981
General Mach Discussion / Re: Help Configuring Limit and Homing Switches
« on: October 23, 2007, 03:54:35 AM »
I am confused about settingup my limit and Homing switches. As you can see in the below drawing each axis has two normally closed switches, one just a limit and the other is both a limit and home switch both switches are wired in series. The breakout board manufacture showed this thpe of switch configuration and I understand that this is possible, I just can't find the way to set it up. The X axis is connected to pin 10 on the breakout board. Mach3 must have a way of knowing the direction it is travling and if it hits a limit or a limit and home switch. The breakout board has Gnd, 10, 11, 12, 13, and 15 for the limits, home and EStop switches.
 How do you configure this? Also If a limit is hit I want to drive off of it automatically, to get out of theh error condition.
I also pasted a the input screen where I think this is done, but don't know how. Please refer to tabs and screens in their exact names, so I can see how to do the setup. Remember this is my first post.

Hi - Your config for your switch setup looks fine as long as you are actually on port 1 and you do have it wired as you say 10,11,12 and common sig gnd. What is not working?

Home function: Mach does indeed know which way it's travelling and therefore when it hits a switch it decelerates, stops and then backs off until the switch is made again. That's home.

Limit function: Mach doesn't care which way it's travelling - any limit switch going open will immediately result in a dead stop. You then have to JOG off the switch. It's not really logical to want this to happen automatically - a limit is an error - it shouldn't happen - it's Machs way of telling you it's gone out of bounds and needs manual (thoughtful) intervention. Suppose for example it hit limit because it has lost steps - it doesn't know where it is - how can it then automatically sort itself out?

1982
General Mach Discussion / Re: Constant velocity
« on: October 23, 2007, 03:20:07 AM »
Art, Brian - many thanks

Ian

1983
General Mach Discussion / Re: edge finding/2.5D probing
« on: October 22, 2007, 01:58:52 PM »
Hi tp - problem sorted - see http://www.cnczone.com/forums/showpost.php?p=356556&postcount=8 onwards.

Now the only remaining problem I have is the possible bug with G31 so as soon as .57 is posted I'll give it a whirl.

Thanks TP - really appreciate your help and interest.

1984
General Mach Discussion / Re: edge finding/2.5D probing
« on: October 22, 2007, 04:01:29 AM »
Stirling the same thing may be causing the problem in both instances(;-) A very POOR  contact at the switch. If the switch has a high resistance at the contacts you can get phantom signals from it as it attemts to make contact. Normally a small capacitor across the two leads will help it clear the contact and make connection. That is the problem with running with a 5volt source there is little energy available to help maintain contact. As a test try raising the debounce setting in config. it may give the switch enough time to settle before mach deals with it.

Yes - I thought of this, so I actually took the probe right out of the equation and just shorted the input pin to ground with a jumper - same problems still happened. Tried messing with debounce and no change.

I've got a thread running on the zone http://www.cnczone.com/forums/showthread.php?p=356625 where we're looking at the possibilities of an unstable (floating) earth. It almost seems like earth is managing to occasionally come up to logic 1.


THe probe tip COMP is in V2.56 BUT there is a small glitch it is corrected in version 2.57 so wait for the .57 version to be posted

I still haven't quite understood how to know when a new release/version/bug fix is in the offing - maybe you could let me know - thanks.

When you get ready to test your plugin let me know I always like to see other peoples work. I usally get to learn something from the example(;-) TP
When I'm happy it isn't likely to trash your probe ;D

1985
VB and the development of wizards / Re: phantom code
« on: October 22, 2007, 03:43:02 AM »
Hi Graham - thanks for your reply

No I haven't specifically put a feedrate in-line - but I do have a feedrate set previously. However I'd re-state that most of the time - lets say 99 times out of a 100, all works fine, but every now and then I get the failure. Having conversed with Art he thinks it may be something to do with the G31 screwing up Mach's timing somewhere. (see http://www.machsupport.com/forum/index.php/topic,4352.10.html reply #17.

Soon as I can get hold of Art's fix I'll try again and see where I get.

Thanks

Ian

1986
General Mach Discussion / Re: edge finding/2.5D probing
« on: October 20, 2007, 03:45:15 AM »
Hi TP - Nice one - thanks Art.

Which version/revision do I download to get it please?

Update on my progress then. I have a 2.5D edge finding/profiling wizard that works fine apart from an issue with what I can best describe as suspected communication sync problems between the Mach thread and the VB thread which occasionally trips it up. I've discussed this with Art and he thought this was probably down to the G31 command as well. Maybe his G31 fix will have resolved that also - I'll need to test it out. (see thread http://www.machsupport.com/forum/index.php/topic,4456.0.html)

The other problem I'm having at the moment is with my setup. I seem to maybe have a dodgy sig/gnd which I'm trying to resolve over on the zone (see http://www.cnczone.com/forums/showthread.php?p=356082#post356082).

Hopefully in a few days, time allowing I'll have an up and running routine for beta testing if anyone's interested in giving it a whirl.

1987
General Mach Discussion / Re: Constant velocity
« on: October 16, 2007, 03:21:38 PM »
seconded... come on folks there must be more than the handful of people in this thread that need CV to work properly... or are you all secretly turning it off or... using T**C?!!!!! ;D

I know Art, Brian et al are busy and have to schedule priorities but with the support this thread is getting it's a no brainer (sic) why it's not at the top of their list.

1988
VB and the development of wizards / Re: How to attach VB script to button
« on: October 15, 2007, 03:49:42 AM »
However after I save, close Mach3 and reopen it doesn't activate the Output 4 led on the diagnostics page.
just writing and saving a macro doesn't mean you've told Mach to run it.
But take a step back a moment - why are you trying to do this? if output pin enable1 has the state pattern you want then why not just use it? - why copy it to another output pin? - they're all just pins after all.

1989
VB and the development of wizards / Re: phantom code
« on: October 14, 2007, 04:51:16 AM »
slight update: It seems I was wrong in thinking Mach 'thought' it had moved. After more checking it knows it hasn't. Here's what happens:

DRO for Xpos says 5

My macro then executes a G01 X-5 in incremental mode. X should of course now be 0 but it's still 5 and there is definitely no movement. BUT the while isMoving() wend loop still goes through several hundred iterations. So it seems that the macro thread is sending the request to the Mach thread and Mach is taking some time to do something before sending the signal back to the macro that it's finished. It's just that whatever else Mach was doing during that time, it certainly wasn't executing the G01.

So, when we send off "code statement" requests to the Mach thread and for whatever reason it fails to honour the request, does anyone know if Mach sets an error condition and/or reason block that can be read by the macro thread?

1990
VB and the development of wizards / Re: How to attach VB script to button
« on: October 14, 2007, 04:13:18 AM »
If GetOEMLed (846 = true) Then
 ActivateSignal(OUTPUT4)
Else
 DeActivateSignal(OUTPUT4)
End If

your code should be:

If GetOEMLed (846) Then

You probably meant

If GetOEMLed (846) = true Then

But there's no need to test against true - that's what 'if' does anyway.