Messages

211

General Mach Discussion / Screen 4 - What am I doing wrong

« on: December 10, 2008, 04:40:25 AM »

I have just moved my touch screen into the workshop and linked it up to Mach 3 - it's great.

I was altering some of the screens - basically to give bigger buttons for my numb fingers, and add jog buttons to the basic set and lset screens. I had a niggling thing happen - when I made an alteration to an icon, say an OEM code, or a picture size, when I pressed OK, the image jumped, usually about 2.5 inches to the left, sometimes, down the screen, and I had to search for it, then bring it back to it's correct position.

What am I doing wrong, or not doing

212

General Mach Discussion / Re: Where did Hoods OEM codes go ???

« on: December 10, 2008, 03:51:59 AM »

Thanks Brett - got it.

213

General Mach Discussion / Where did Hoods OEM codes go ???

« on: December 09, 2008, 11:38:50 AM »

Hood - I lost your OEM codes recently, and thought - it doesn't matter, they are on the forum - only to find 

THEY'RE GONE.

Please - where are they

214

General Mach Discussion / Re: Spindle and Speed control Section

« on: December 09, 2008, 07:13:34 AM »

Peter - Good idea

215

General Mach Discussion / Re: Homing gantry with smooth stepper

« on: December 08, 2008, 04:11:24 AM »

I have no idea about using axis as slaves - but reading your post, it would seem to me that perhaps the "home" input of the slave axis is not working properly. You say that your gantry will move to home, hit the switches - then you seem to say that one axis backs off and stops, but the other backs off, but carries on until the thing physically locks up. The keyboard etc is frozen until you hit reset.

It seems to me that the secong "pulse" on the second axis is not being detected. When homing, the switches are hit and go either positive or negative (depending on how you have it wired up), The direction of the motor is changed until your switch opens (or closes) again and gives the second signal to stop. It seems to me that the second signal (of the secod switch) is not getting to the computer. The computer is still waiting for the second signal, and therefore appears to be locked up.

If it is possible, I would run the gantry with each side alternatly free wheeling - remove the drive belt or something, so that the gantry can move, and the computer thinks all the electronics are fastened up. Then run the homing routine, and see if each side runs properly. I don't know how big a gantry you are talking about, and you might have to give it a gentle helping hand to keep straight, or whatever, but you sould see the basic movement at the switches.

Another possiblility has come to mind - I take it both switches home almost "together" time wise. I do not know whether you have these on the same circuit, or different circuits. As I understand Mach 3, the limit and home switches can be wired together. If "homing" is chosen, the system works as "homing" switches, until such time as the homing function is finished, and it then reverts to "limit" switches.

In your scenario - could the system be operating "home" switches  together - until one switch completes the cycle, and then the other switch becomes a limit switch. This woulld normally stop the system - unles you have "Auto limit overide" selected, which will allow it to carry on and back off the switch, therefore locking up your gantry.

If this is the case, you could probably write at Vis basic macro, so that homing takes place, using the drives together (but only one switch), then after the first axis has finished, moving the other axis (using the A drive on its own) "home". This should work.

216

General Mach Discussion / Re: Auto Tool Zero

« on: December 08, 2008, 03:30:52 AM »

Tweakie - I am not saying that you should't use opto circuits to isolate the inputs to the computer. However - it is safe to plug things directly into the port - look at all the things you plug into a computer. What you have do do is keep within the tolerances of the port.

The only trouble as far as I can see, is that all these isolating circuits introduce complications. I don't think I would worry about the  CNC4PC board and other boards, if the inputs had not been reversed. The input to the computer is designed so that in-going signals pull down the pin to zero - a fairly standard electronic move, and one which many compenents are designed to do, simple to design and relatively safe - i.e. 0v is 0v.

Why then leave all the complications to us - why not replicate this on the breakout boards - i.e. a negative going signal produces a negative going signal to the computer. We on the outside then have all the advantages of component design for our benefit without having to workout how to invert the input.

A very simple example is the opto switches I use on my machine to detect homing and limits. The opto circuit (as bought) is designed to produce a 0v signal, when it detects. It is simple and efficient - requiring the component and a resistor (to regulate the power supply (5v) to the input side) - very fast Scmidt trigger - and accurate to 0.000x of a thou when in use. I feed this directly to my LPT1 - via my breakout board, which is non-powered (just a set of connectors really). Using a powered opto breakout board there would have to be another set of electronics between the switch and the computer,introducing time lag (slight), degeneration of the signal, changes of polarity, etc. - and wait until things go wrong - where is the fault??

My advice is keep it simple as can be - lets get onto manufacturers and have a common standard to work to (much as the railway modellers did in the States) - so that our stuff is really "Plug and Play" - and problems like this can be avoided.
 

217

General Mach Discussion / Re: PWM spindle control - Smithy 622 - Help Please.

« on: December 05, 2008, 01:32:41 PM »

I have not tried this, so you will have to bear with me as I am thinking through it. If, if the normal course of things, you wish to retain the standard M3 (forward) and M4 (reverse) commands, and M5 off, this would seem to be a good idea, since a lot of CAM programs will be geared to that form of command.

It seems to me that when M3 is selected, then you need to put +5v on the "direction" pin and enable the "PWM" pin.
conversley ------------  when M4 is selected you need to put 0v on the "direction" pin and enable the "PWM" pin.
When M5 is selected, you need to disable both pins.

This would seem a job for a brain - and I haven't done anything with brains - any brain fans out there

218

General Mach Discussion / Re: No Pulse Frequency!

« on: December 05, 2008, 01:15:36 PM »

I know this sounds daft, but try installing mach 3 BEFORE you install service Pak 3. As a matter of fact, if all this computer is to do is run Mach, you don't need Service Pak 3.

I think I have the same mother board in my computer, which I have just installed in the workshop. Everything ran in alright and worked first time (apart from a glitch where, for some reason, the LPT1 output had been disabled).

I have since installed service pak 3 and it is still running, although one or two have reported difficultulties.

219

General Mach Discussion / Re: Mapping output #6 to another pin?

« on: December 05, 2008, 01:08:20 PM »

If you are using the LPT1 port, then you can't use pin 15  which is an input and cannot be changed to output. The other outputs are 1,14,16 and 17.

If you are using some configurable input/output board, then yes.

220

General Mach Discussion / Re: Mach3 skips to subroutine, crashes Z, ruins part :(

« on: December 04, 2008, 04:45:40 AM »

The problem is, with offset tables, they change themselves without notice if you are not careful. Before I get cries of "Oh No" let me say that they change because the operator has done something (not literally by themselves)

The particular one that always catches me out (although not recently) is zeroing the DRO's in Program Co-ordinates, after I have zeroed the machine in Machine Co-ordinates.. The thing being, after you have zerod your machine in Machine Co-ordinates NOT to then zero the Part co-ordinates unless the machine is at 0.0.0, otherwise the selected offset is altered to reflect the current offset of the machine.

The machine then seems to work fine for the first cut, but when it then changes to a different offset, the second offset was not in the proper relationship to the first offset (if you get my meaning).

Your problem, however, does not appear to be that - from what you say, the machine is suddenly changing its program. As you know, Mach3 reads ahead, and it appears, correct me if I am wrong, otherwise we are looking in the wrong place, that the machine is gaily returning to base, job done, then Mach3 reads ahead, sees another sub-routine call, and picks the wrong one and starts on that.

I assume you are using mach3 in the normal way, the main program being in the GCode file and Sub-routines being in the Sub Routines file under a seperate name.

I would be tempted to do a little housekeeping on my computer, behaps run a Disk Clean Up and a Defragmenter so that all the  loose ends of files are properly tied up.

I don't know what else to suggest at the moment.

Jim.