Hello Guest it is May 28, 2024, 04:06:51 PM

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 - Steve Stallings

Mach4 General Discussion / Re: what is wrong with this g code
« on: August 16, 2022, 02:46:09 PM »
I have not figured out what is wrong, but I did get different preview results from you.

For me the Mach4 preview looks to match the Vectric one.

I happen to be running build 4818.

My only issue with the ESS is that their plugin configuration takes over many functions that are normally done in the standard Mach configuration screens. This is, for me, confusing. Overall the ESS is an excellent product and I do not think it is the cause of your problems.

Yes, the on screen jog buttons can be modified, but it is far more common to find that users change the keyboard ones without understanding the system. I was trying to find a way to avoid Gcode issues and prove that Mach4 was working correctly. Comparing DRO readouts to observed machine motion was the critical part.

I guess it is possible that the old setup had the Y axis misconfigured and original poster did not realize that he had worked around it by changing the Gcode. The replacement PMDX-411 is on the way to him and maybe he can reload his old configuration to check that. The testing with using the on screen jog buttons to verify that the DROs and machine moved in the correct direction convinced me that Mach4 was driving the machine correctly in this case. Sometimes people get confused when one axis moves the cutter and the other axis moves the table. I wonder if that could be the source of the problem.

This case is more than just configuring the motor direction correctly.

The DROs and machine run correctly if you use the on screen jog keys.

When Gcode is run, one axis moves backwards. The Gcode itself has been supposedly been validated on his older setup with a PMDX-411. We have been trying to figure out if a G51 parameter is stuck somewhere. Adding a G51 Y-1.0 to the Initialization string in Mach4 makes things work correctly.

I recommend using on screen jog buttons to confirm operation while testing and adjusting parameters. That way you can avoid crashes.

Also confirm that the on screen DRO moves in the expected direction even when machine goes the wrong way.

If that is the case, there must be a configuration problem.

The direction that a motor runs can be affected by many things.

The Config>Control>Motors tab can be used. Highlight the desired motor on the right side of the panel and look for a check box at the bottom for Reverse.

The polarity of the direction signal can be configured in the ESS plugin.

The wiring polarity of the stepper driver outputs to the motor coils can change the direction, though this likely does not apply in this instance since you probably have not changed any of this wiring.

Note that the direction of jogs using the keyboard can be configured independently of all of the above and it is possible to have the keys mapped differently from other motion sources. Using on screen jog buttons would bypass this issue.

Lastly, it is common for machines to be configured such that the home switches double as limit switches. This is done by setting up duplicate entries in the Input Signals table such that the same signal is used by Home and by Motor1--  for example.

Mach4 should stop ALL motion if ANY limit switch is tripped. You should use the Diagnostics tab to view the hardware Input Signals to confirm that limits are configured and working. This screen is accessed from the Diagnostics tab at the right end of the same line of tabs the begins with Program Run, not the Diagnostic tab at the top line of the screen.

Your speed readings for each speed except the two highest are all close to 22% high.

The PMDX-107 used with most VFD's can normally achieve a speed setting accuracy of 5% or better over most of the range.

First, make sure that you have the default slot for pulley 0 configured in Mach4 to Min RPM of 0 and Maximum of 24000 (or 24001 if Mach complains when you select 24000). These numbers are used by Mach4 to calculate the PWM percentage. The case of protecting the spindle from cooling problems is normally covered by the motion controller plug-in overriding the minimum PWM. The PMDX motion controllers allow this, but I am not sure how this would work for a SmoothStepper based system.

I suspect that your VFD or its internal settings are scaling the input voltage by +22% and the two highest speeds are being limited by the maximum 400 Hz range of the VFD.

You could try using Mach to request some speed safely below the limit, say 18000 and then use the CAL pot on the PMDX-107 to get 18000 at the spindle. Not sure how this will affect the maximum speed you can reach, but it should cure the +22% over most of the range.

Alternatively you can dive into the gain or span settings in your VFD's parameters, but this can get complicated and confusing quickly. If you go this route be sure to document your VFD's parameters before changing them. It might also be informative to see if any of these parameters are not currently set to their factory defaults. Lastly if things are really messed up you can use the VFD's reset to factory defaults option.

Mach4 General Discussion / Re: Mach4 API/SDK
« on: June 19, 2022, 03:44:47 PM »
LUA scripting is recommended and supported as the primary method of enhancing functions in Mach4. This is an interface that allows most functions and can be tightly secured against system hacking. These functions include most of the things that are available in the API, but not all such as the functions to install as a device driver.

Installing device driver plugins allows much higher risk to system security and therefore the extra precautions. Plug-ins must utilize an encrypted handshake to be allowed to integrate with the core. Registering as a authorized developer includes being issued a unique security key so that if someone compromises the key Newfangled Solutions has the option to block the compromised key.

Mach4 General Discussion / Re: Mach4 API/SDK
« on: June 19, 2022, 03:16:14 PM »
The file Mach4CoreAPI.chm is a document file in the DOCS folder that explains using the Mach4 API from compiled programs that access the API but are not actually linked with the core code. Windows knows how to open and navigate a .chm file and you just double click on it to open.

Usage of the SDK to build programs that fully integrate into Mach4, such as device driver plug-ins, requires developer status and you must request that from Newfangled Solutions and enter into a non-disclosure agreement with them.