Messages

1221

General Mach Discussion / Re: Steps per Inch Question with Slaved Axes

« on: March 04, 2021, 11:14:09 PM »

Hi,
I've been using Mach4 for six years, and I know that there is a vastly better and more flexible method for slave motors.
My machine does not have a slave axis and so I can't comment on whether it is possible to have different settings for each motor
on a multi-motor axis, if had had been left to guess then I would have said no, you could not do that....but the truth is I don't know.

What is true is that you can programmatically link/unlink motors on the fly, change settings programmatically and various other clever
options that come about because of the architecture of Mach4/Lua, and would surmise that what you want to do is possible, even if the direct
method is not possible.

Mach4 is a learning curve, and many get frustrated while learning and quite a few give up. Those who persevere do end up with a vastly better
CNC solution than Mach3.

Craig

1222

General Mach Discussion / Re: Steps per Inch Question with Slaved Axes

« on: March 04, 2021, 08:11:50 PM »

Hi,
to my knowledge a slave axis must have identical 'steps per unit', max velocity and acceleration as the main axis.

Is there a mechanical reason one motor should not move as far as the other despite turning the same angular amount?

Craig

1223

General Mach Discussion / Re: AKZ250 BOB Mach3 Question?

« on: February 17, 2021, 02:49:21 PM »

Hi,
the only thing to recommend that motion controller is that it is cheap.

Consider an Ethernet SmoothStepper ($180USD), firstly it has Ethernet comms which has better noise immunity and faster throughput.
It has 51 IOs, more than enough for multiple buttons etc. It has both Mach3 and Mach4 plugins should you ever decide to upgrade.
Note the the ESS is a motion controller only, you'd still require a BoB or BoBs, for instance a C25 ($29) with two ports or multiple C10's ($23 each)
with one port per board.

Craig

1224

Mach4 General Discussion / Re: Lua Error while running chunk

« on: February 16, 2021, 09:17:58 PM »

Hi,
this post belongs in the Mach4 General Discussion board.

The script, ScreenScript.lua, is a file that gets composed of all the Lua fragments, they all get rolled into one file and compiled.

The fault occurs at line 1614 in that file.

My guess is that you have a poorly or incorrectly defined parameter and when Mach goes to compile the code it fails. That's what the
stack traceback is all about, and in particular the line number.

Note that even once you find the offending line you cannot edit ScreenScript.lua directly, you have to edit the source Lua fragment
which is incorporated into ScreenScript.lua.

Craig

1225

Mach4 General Discussion / Re: Signal Number Definitions

« on: February 14, 2021, 11:42:16 PM »

Hi,
I had a look for that variable number also, but couldn't find it either.

I am not aware of anymore authoritative source either. NFS's response is usually along the lines that the assignment of a pound variable number
for a given piece of data is at NFS's sole discretion and is likely to change over time. They claim any and all useful data is covered by the
ENUMS, and they are in turn NOT affected should at some later date a pound variable number be changed.

If you do discover what it refers to please post it so we can update the lists......its people contributing what they have discovered that those lists exist at all.

Craig

1226

Mach4 General Discussion / Re: Signal Number Definitions

« on: February 14, 2021, 09:42:17 PM »

Hi,
try this post:

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

Craig

1227

General Mach Discussion / Re: Mach3 and latest ESS Driver - threading now works!

« on: February 12, 2021, 02:25:23 PM »

Hi,
spindle PID is for Mach4 only, it does not work in Mach3.

Clarification: This refers to realtime spindle PID enacted by the ESS

Craig

1228

Mach4 General Discussion / Re: Spindle speed not correct

« on: February 10, 2021, 02:54:23 AM »

Hi,
HuanYang are famous for having non-Modbus compliant comms, that's the reason for the special plugin in Mach3
for these VFDs.

The manufacturers must have taken a lot of heat over the non standard comms because they have released later models
which are compliant.....just they are more expnsive....so people still buy the el-cheap ones with this result.

I'll try to find the model identifier, its something like HuanYang nnnn.GM, with the GM, or some other accronym signaling
compliance with the Modbus standard.

Craig

1229

General Mach Discussion / Re: New member, some mach 3 setup questions and UC100 intermittent connection issue

« on: February 06, 2021, 02:06:49 PM »

Hi,
I suspect that by elevating the priority of Mach3 that it suffers less interruptions and therefore the UC100, or rather, the USB connection
to the UC100 runs better.

As a side note Windows makes such extensive use of the CPUs interrupt system that it cannot ever be 'realtime'.
It is this lack of realtime determinism that prevents Windows/Mach from being a feedback controller, Mach, in fact all
Windows based CNC software solutions, must be 'buffered'.

Compare that to LinuxCNC, it runs on a realtime capable distro of Linux and it can creditably be a feedback controller.

Craig

1230

General Mach Discussion / Re: New member, some mach 3 setup questions and UC100 intermittent connection issue

« on: February 05, 2021, 08:24:32 PM »

Hi,
in the early days of Mach3 everyone used Machs parallel port driver as motion controller. The parallel port driver is an interrupt timer
based pulse generator, and it was, and still is, a marvel that it operates as well as it does in a Windows environment.

Windows make very VERY extensive use of the CPUs interrupt system and therefore Machs parallel port competes with Windows for
interrupt service. It is possible, to a limited extent, increase an applications interrupt priority, but if you over-do it you will crash Windows.

I suspect the advice you were given about increasing Machs interrupt priority dates from that time.

Given that you are using a UC 100 there is no parallel port driver running and therefore there should be no interrupt competition.
The UC100 is USB connected and can and occasionally is out-competed by other applications or services running on the PC. For this
reason you are advised never to run any other applications and only ever run the bare essential services on your PC so that Mach and
its USB connection to the UC100 is not interrupted in any way.

USB data packets are initiated every 10-12ms or so whereas Ethernet packets are initiated a less than 1ms intervals. Ethernet communications
can miss entirely one or even two packets and yet still maintain quasi continuous comms and are therefore more robust and less likely to
run-out-of-data, or loss of sync.

A related issue is that USB packets are rather more susceptible to corruption from electrical noise, and as each packet is larger takes even greater
time to re-transmit, increasing the probability of a run-out-of-data error. Using the shortest high quality cables with at least one ferrite but better
still, two ferrites is recommended to avoid the problem.

Craig