Messages

551

General Mach Discussion / Re: Can you Explain NC Code?

« on: August 15, 2022, 03:24:26 PM »

Hi,
OR use MasterCAM properly.

MasterCAM is by far and away better than CAMBAM or any other Johnny-come-lately CAM program having
been in continuous development since the eighties. The only other CAM program that comes close is HSMWorks.
Both of these programs cost over $20,000 plus annual fees.

If I could afford either I would have them....fullstop. Sure they have a huge learning curve, but that's what you get with the most
comprehensive CAM programs on the planet.

Craig

552

General Mach Discussion / Re: Can you Explain NC Code?

« on: August 14, 2022, 08:20:47 PM »

Hi,
the early M6 is quite common. The machine is being set up to do the job, so the CAM program calls for the tool to be used. The fact that it may already be in the machine
and therefore no M6 is actually required is completely unknown to the CAM program, so it calls for an M6 to ensure that the right tool is used. Likewise it will call a G43
for the tool, after all the tool length offset is an important parameter, that you have arranged it so the tool offset is not required is again unknown to the CAM program.

As far as the G3 moves, use MasterCAM to simulate the toolpath, is the toolpath correct? The rule is to use the CAM program to simulate the toolpath rather than doing a dry run on the
machine. That absolutely requires that the CAM program have a perfectly accurate description of your machines motion characteristics, things like axis orientations etc.
MasterCAM has an excellent, albeit difficult to use, machine description module. It will take many hours to learn to understand the machine description module but is essential if you want to
produce sensible code without you coming along and editing it.

Craig

553

General Mach Discussion / Re: Mach3 Estop triggered when spindle stops

« on: August 14, 2022, 06:57:38 PM »

Hi,

Would a high debounce time cause any issues for the homing/limite switches?

Debounce is applied to each individual input. If you applied excessive debounce to either homing or limit switches then yes it will effect the response of homing
and/or limits. The debounce on the EStop input would have no effect on homing/limits.

what sort of value for debounce is thought of as standard?

There is no standard. The general rule is to use the minimum necessary to get good results. If that requires excessive filtering (debounce) then that means you have a problem
elsewhere interfering with your circuit and you are just using filtering to cover another fault.

Craig

554

Mach4 General Discussion / Re: ESS + Mach4 - feedrate problem

« on: August 14, 2022, 06:51:21 PM »

Hi,
as your code is written I would expect the the X axis does 1273, or some close approximation, and the Y axis do the same, thus the blended speed is:

Blended speed= (1273²+1273²)^1/2
=1800

Is that close to your observation?

Craig

555

General Mach Discussion / Re: Mach3 Estop triggered when spindle stops

« on: August 14, 2022, 06:46:44 PM »

Hi,
this is just my guess but as the spindle starts to decelerate a voltage spike occurs and that is somehow being coupled into your Estop circuit.
Given that it is an electromagnetic process it may well occur randomly.

Try a very long time constant debounce on you Estop circuit, or maybe even disconnect it altogether....does it change anything?

Craig

556

Mach4 General Discussion / Re: Configuring limit switches

« on: August 14, 2022, 06:40:47 PM »

Hi,
This post belongs on the Mach4 General Discussion Board....this board is about Mach3. No doubt Tweakie will shift it in due course.

What plugin are you using for the UC100? Where did you get the profile....did you make your own or did you import it from somewhere?
Does the plugin diagnostic show a dedicated EStop input?. If it does is the pin configured Active High or Active Low?

Craig

557

General Mach Discussion / Re: Mach3 Estop triggered when spindle stops

« on: August 14, 2022, 06:34:56 PM »

Hi,
I suspect that when the spindle is being called to stop that it is generating a voltage spike which is causing the Estop.

When the spindle is spinning and then stopped as the spindle winds down it is a generator and can generate back into the power supply.

What is the spindle? How is it driven? Do you have agressive acceleration/deceleration setting for the spindle? Does it have a braking resistor?

Craig

558

Mach4 General Discussion / Re: Physical home switches with linear encoders

« on: August 14, 2022, 05:26:15 PM »

Hi,
if using Mach4 then this post belongs on the Mach4 General Discussion Board.....this board is about Mach3. No doubt Tweakie will shift it in due course.

Homing is a realtime procedure that is entirely enacted by the motion controller, not Mach4. When a Home switch activates the machine must respond imediately, or at least
within microseconds. The communication delays from the motion controller board TO Mach4 and then FROM Mach4 back through the motion control buffer would be a delay of
100 milliseconds or more, way, way too slow. Ergo the motion controller must do the job, and is one of the foundational realtime supports that a motion control must offer
to be useful.

Most motion controllers for Mach4, like an Ethernet SmoothStepper can read an encoder, but to my knowledge cannot trigger a Home event based on the output of an encoder.
Remember also that when a machine is Homed or Referenced it is the Machine Coordinates that are zeroed, and you cannot manipulate Machine Coordinates directly, in fact you
can ONLY set them as a Homing or Referencing operation, ie the motion controller alone can set the Machine Coordinates, and the motion controller requires Home switches.

I think Homes switches are in order for a simple and direct solution. I could forsee a couple of methods that might allow the use of linear scales to set Machine Coordinates, but
the complexity counts against them.

Craig

559

Mach4 General Discussion / Re: lua in Mach 4

« on: August 09, 2022, 09:54:40 PM »

Hi,
when I'm coding Lua, this link is permanently open in my browser:

https://www.lua.org/manual/5.3/

It tells you about the basic syntax, control structures, scope etc. My guess is you'll use the Standard Libraries quite a bit too.

The next thing you want open and you will consult dozens of times per hour is Mach4CoreAPI.chm, its the API Help file, found in C:/Mach4Hobby/Docs.

It helps to know about Machs structure and organisation but if you are reasonably familiar with the API and can refer to the Lua Reference Manual,
the link above, then you'll be able to handle 90% of what comes up.

Craig

560

Mach4 General Discussion / Re: lua in Mach 4

« on: August 09, 2022, 07:29:48 PM »

Hi,

In short i want to build a text variable that contains mc.OSIG_OUTPUT# as text and use that value in the statement seems that would be the most efficient

That does not work in Lua. In order to address and either set or read a variable you must first get its 'handle', which in effect a number corresponding to the memory location of the
variable.

For example:

local VariableHandle=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT5)
mc.mcSignalSetState(VariableHandle,1)

So the only way you can address a signal is by using its handle. That's the way Lua is and always has been.

Unlike languages that you may be used to which have a variable table and using it you can address any variable you require and remains fixed for the duration of the program.
In Lua variables come and go and are located in different addresses as the program progresses, in fact many of them are in a stack which will be garbage collected once the variable
goes out of scope.

Lua is not really a computer language, but rather a scripting language, and is meant as an extension to the main program. In the case of Mach the main program is all C/C++, and
Lua is the scripting language laid on top of it for our use.

So when a Lua function is encountered  the PC sets up a stack and all variables (local) are put (called 'pushing') onto the stack while the function runs, so the memory location of a variable is changing
as new stack entities are 'pushed' onto the stack or 'popped' off it, ergo the repeated and common use of a 'handle' rather than a textual variable name.

You may find the PDF I wrote about using the SignalScript and covers some of these ideas useful:

https://www.machsupport.com/forum/index.php?topic=40051.msg267764#msg267764

Craig