Messages

1111

Mach4 General Discussion / Re: MACH 4 G1 CMD DOES NOT WORK

« on: August 18, 2021, 11:35:46 PM »

Hi,
more as a matter for clarification Mach4 treats ALL Gcode as lowercase, without leading zeros and without whitespace.
Whenever the Gcode interpreter operates it will first alter all Gcode to suit.

G0 X0.01 Y3.01 gets interpreted g0x.01y3.01     and
G1 X4.98 Y    0.76 Z50 F400 gets interpreted as g1x4.98y.76z50f400   etc

In most cases Mach will interpret Gcode you have supplied it without problem but there are a few occasions where it
does not and it can be very hard to spot why. May I suggest you follow the rules of Mach4, ie all lowercase, no leading
zeros and no whitespace as it will circumvent that problem.

Craig

1112

Third party software and hardware support forums. / Re: How to use GPIO on Dell Embedded PC for additional Mach 4 inputs and outputs?

« on: August 18, 2021, 01:06:23 AM »

Hi,
you could probably use those IOs but they would not be fast.

In Mach4 you have a 'active motion controller' in your case the AXBB-E. Inputs to this controller, things like probe,
limits and home switches are acted on by the board immediately, also called realtime. They will in turn be passed onto Mach but the communication
delays could be tens of milliseconds. The delay would totally screw the functionality of those inputs that require immediate or realtime service
including probe, limits and homes. All of these inputs MUST be handled on the motion control board without assistance from Mach4.

Note that you can only have ONE active motion controller and therefore only the inputs available on that controller can be used for realtime purposes.
I'm not sure but I believe the AXBB-E is similar to my Ethernet SmoothStepper in that it expects to be the active motion controller, and as I've already
said there can only be one active motion controller, that means that you can use ONE and ONE ONLY AXBB-E or ESS.

What you can do however is have another device with its own plugin and that could for instance handle IO. What it could not do however is handle
realtime events, say an extra probe circuit. You'd have to find room on your primary motion control board for it. What it could do though
is turn on and off pumps, lights or monitor door switches for example. Who cares if they take a few hundred milliseconds to get back to Mach or take a few
hundred milliseconds to get from Mach to the pump say.

If you wrote a plugin you could have Mach use the GPIO pins of your PC. Writing a plugin is no small feat, but possible.

I believe there is a better and far easier solution though. PoKeys made their name in digital IO boards long before they made a motion controller for CNC
purposes. Their 57CNC has at its core a 57E, an IO board. What I would suggest is get a 57E and its Mach4 plugin. Then you would have up to 55 inputs
and outputs several of them (7) analogue capable.

Within the understanding that all IO via this second board cannot be realtime would an extra 55 IOs be enough? I think a PoKeys 57E is around $70.

Craig

1113

General Mach Discussion / Re: Mach3Turn interface messed up not usable?

« on: August 18, 2021, 12:32:45 AM »

Hi,
I notice the carefully obscured licensee name at the top of the screenshot. Is your copy of Mach3 licensed?

Craig

1114

Mach4 General Discussion / Re: Mcode does not run from Gcode nor MDI

« on: August 16, 2021, 08:02:30 PM »

Hi,
think I've solved the problem.

I installed a new version of Mach but before I did so I saved and copied my original entire Mach4Hobby folder as an archive.
Once I had installed the new version I imported my profile from the archived folder. All my original macros, including the .mcs
AND .mcc files came across. What did not travel over was the mcLua.mcc file.

My understanding is that this is the compiled version of all the macros combined into one chunk and it is this file that Mach uses at runtime.

What I did was to delete all .mcc files from my Profile/Macros folder and restarted Mach. Mach very nicely recognised that there were no
complied files on which to operate and so proceeded to compile them all including mcLua.mcc. Now Mach will run Mcodes from
either a Gcode file OR MDI....I'm back in business.

Craig

1115

Mach4 General Discussion / Mcode does not run from Gcode nor MDI

« on: August 16, 2021, 07:18:51 PM »

Hi,
yesterday I updated to the latest build of Mach4Hobby and ESS plugin.

Now I have a problem that my macros will not run from either a Gcode file nor MDI, despite the macros running properly if I use
the Lua editor.

I feel there is something basic I'm missing.....and cannot for the life of me remember what it is.

Craig

1116

General Mach Discussion / Re: machine goes haywire when plasma fires

« on: August 16, 2021, 03:06:16 AM »

Hi,
a plasma arc is like 'controlled lightning' going off on a machine connected to a computer. Most people would
say mixing lightning and a PC is foolish...and they'd be right.

One often overlooked source of electrical noise getting into your PC/controller/BoB is via the power supplies.

When plasmas operate they draw a great deal of current from the incoming domestic AC supply. Most modern plasmas are
electronic in nature and most, certainly all the Chinese ones, have no power factor correction built in, and thus they pollute the domestic supply
with very troublesome current harmonics. These harmonics are easily conducted into the PC power supply and the controller/BoB
supplies and play merry hell.

You might try as an experiment plugging the plasma into a separate circuit than the PC/controller/BoB. If this helps then
I would recommend a line reactor at the input of the plasma, it will seriously tame those current harmonics. Also a two, or even better three stage,
line filter at the AC input to your PC/controller/BoB will help keep conducted noise out of those components. Don't scrimp, get the gest line filters
you can afford.

This is a 3 phase line reactor, which if you wire all three windings in parallel with careful attention to the phase dots, will give you an excellent
12A line reactor:

https://nz.element14.com/block/lr3-48-3-4/line-reactor-3-phase-5-5mh-4a/dp/2751043

This is a suitable 10A two stage line filter:

https://nz.element14.com/corcom-te-connectivity/10emc1/filter-10a-1-phase/dp/9586474?st=line%20fiters

Over and above preventing conducted electrical noise from entering the power supply input of your PC/controller/BoB
you must now turn to minimising the susceptibility to noise.

Is your controller USB connected? USB connections are very susceptible. Make the connection as short as possible, preferably
with a ferrite ring core close to each end, or even better get an Ethernet connected controller, they are better in a noisy environment.

Craig

1117

Mach4 General Discussion / Re: Mach4 not running on Windos 7 32bit

« on: August 15, 2021, 05:56:56 PM »

Hi Steve,
thanks that worked. I have successfully loaded the 4735 version and the latest ESS build (278). Given that I've recycled my profile
I have not encountered anything about this new version than the old (3481)

The VS x64 version will not load, I'm running 32 bit Windows7 Embedded Standard on my machine PC, so it should probably come as no
surprise that a x64 version won't load.

Thanks
Craig

1118

Mach4 General Discussion / Re: Mach4 and Autoleveller issues ( CSMIO IP-M)

« on: August 14, 2021, 03:51:02 AM »

Hi,
I use AutolevllerAE and have done for years.

The message you are getting is from the m41 script which I wrote.

In Mach3 there were two macros M40 and M41 that open a probe data file and M41 closed it. Mach4 does not natively have those two macros.
It does ship with two examples, m400 and m401 which essentially replicate the Mach3 M40 and M41. I took those examples and in the case
of m41 modified it extensively to qualify the data. The message you are getting is because the macro recognises non-compliant data in the probe data file.

There is a subtle difference between the way Mach3 and Mach4 records the data. In the case of Mach3 it records the X and Y coords
direct from Autoleveller and the Z coord from the measurement performed by the G31 move. Mach4 on the other hand records the actual
X and Y coords plus the Z measurement from the motion controller. In an ideal world the X and Y coords would be identical wit the X and Y
probe point supplied by Autoleveller. In reality the machine X and Y may differ very slightly, with my machine at that time, I measured a difference
of 0.02mm on average. The problem arises when Autoleveler goes to calculate the Z axis corrections. If the measured and ideal X,Y coords differ
by as much a 1 at the fourth decimal place then Autoleveller screws up royally and calculates wild variations in Z, which if undetected will
result in your machine crashing BIGTIME.

The second thing that M41 does is check that there are the right number of data triplets in the probe data file  as there is probe points in Autoleveller PGF file.
At that time there was a quirk of my ESS controller that would sometimes record an occasional extra data triplet or two. Thus if Autoleveler decides to probe the
PCB 110 times but the data file could have 112 data triplets, then Autoleveller would screw up. My macro counted the data points and compared to what
Autoleveller  PGF file demanded.

The ESS quirk that caused that issue was fixed six years ago so this fault only now happens if the probe routine screws up somehow....I've had it happen
twice in over a year. I doubt therefore that is what is causing your issue.

So getting back to the message, if the macro detects that the X,Y coords reported by the motion controller differ by more than 0.02, or whatever
you set the parameter Atol to, then it would generate an error with message. I suspect that your raw data is being compared to what Autoleveller specified
and there is a large difference between them. You could ignore the message and have Autoleveller calculate the Z axis corrections but I would expect
it to be BIG TROUBLE.

Print both the ProbeDataFile  AND the Autoleveller generated PGF file and compare the two closely. Can you identify each requested probe position with each data
triplet? That is in effect what my macro does and has been doing for me hundreds upon hundreds of times over the last six years.

Craig

1119

Mach4 General Discussion / Re: How to attach "Go Home" to the numeric keypad

« on: August 08, 2021, 11:18:08 PM »

Hi,
Have a look at DazTheGaz's video and you'll find a nifty trick to cause any keyboard key to trigger a script,
RefAllHome for instance.

https://www.machsupport.com/forum/index.php?topic=31585.0

Craig

1120

Mach4 General Discussion / Re: controlling JP-3163B in 6040T USB CNC with Mach4

« on: August 08, 2021, 11:12:53 PM »

Hi,
the probe is an input into Mach4.

The UC100 in a sense mimics a parallel port and replicates a parallel port numbering.

pin 1   output
pins 2-9 outputs
pins10-13,15 inputs
pins 14,16,17 outputs.

You need to decide which of the very few inputs you have to spare, pins 10-13 and 15, and connect one of them to your probe.
Then in the UC100 plugin you need to connect that pin to Machs Probe signal.

Craig