Hello Guest it is March 28, 2024, 04:51:02 AM

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 - MrFixit

Pages: 1
1
Hi,
I have and use an ESS and use probing extensively for making circuit boards.

I have a software utility (Autoleveller) that generates a Gcode job to probe the PCB blank and record the z position of the surface. It will probe a PCB
50 or more times in a grid fashion. If the probe for whatever reason does not make contact before it reaches the end of travel as programmed by the G31
code then the program halts......that's what I would expect.

You have issued an instruction 'go to location z=nnnn and stop on contact and report the z position', if it does not make contact within its given range is that not a fault?
What would you expect Mach to do?.

In the case of my PCBs, if Mach just carried on and entered a -1mm z ordinate, -1mm being the max z extent of the G31 move, then my levelling program would fail miserably
by virtue of poor data.

Craig

Hey Craig, In your application that makes perfect sense.  I don't see any fault in your logic.  I always appreciate you taking the time to read and reply. You are an awesome contributor to this forum.

I want to explain where I'm coming from not to challenge you, but to hear how you would handle it or what your opinion is on the whole mess.

I also want to say that I bought a ESS and an MB3 as a means to solve this problem since i got no reply or answer back from CNCdrive about the plugin for my AXBB-E.
I havent installed it yet, so the rest of this reply still applies to what happens with the AXBB-E.

Mach Support did respond to my support email and confirmed that it is up to the plugin creator to add the functionality/option of ignoring a no contact condition in a G31.
Their exact response was this
Quote
Hello,
Controllers like the ESS have a setting that allows you to proceed if using a G31 and you make no contact.
By default a controller will error out however unless they've included a setting in their plugin that ignores the no strike condition.
Best Regards,
Trevor

 
The reason the probing behavior as described above is an issue for me is that the Mach4 probing scripts are written with G31 instead of G01 for preparatory machine moves.  For example on the 2 surface outside centering X direction the mcprobing script reads as follows(excerpt).  I added a couple comments on the right of the lines i am referring to.

Code: [Select]
------------- Probe Surface 1 -------------
local ProbeTo = CurPosition + (XWidth / 2) - OverShoot
local RetractPoint
local rc = mc.mcCntlGcodeExecuteWait(inst, "G0 G90 G40 G80")
mm.ReturnCode(rc)
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G43 H%.0f", OffsetNum))
mm.ReturnCode(rc)
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f X%.4f F%.1f", ProbeCode, ProbeTo + Approach + OverShoot, FastFeed))            --This line is an X move over the part from the centerish starting point to past the expected part edge.
mm.ReturnCode(rc)
rc = Probing.CheckProbe(1, ProbeCode); if not rc then; do return end; end
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f Z%.4f F%.1f", ProbeCode, ZLevel, FastFeed))                                    --This line is an X move to the specified probing height for probing
mm.ReturnCode(rc)
rc = Probing.CheckProbe(1, ProbeCode); if not rc then; do return end; end
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f X%.4f F%.1f", ProbeCode, ProbeTo, FastFeed))
mm.ReturnCode(rc)
rc = Probing.CheckProbe(0, ProbeCode); if not rc then; do return end; end
local ProbePoint = mc.mcCntlGetPoundVar(inst, mc.SV_PROBE_POS_X)
if ((ProbeTo + Approach + OverShoot) < ProbeTo) then
RetractPoint = ProbePoint - BackOff
else
RetractPoint = ProbePoint + BackOff
end

 
This is the way the lua script is consistently written in the mcprobing module. 
The end result is that simple probing actions such as finding a single surface or finding an inside center work for most people since there are no prep moves.

However on more complex probing sequences, i get the hangup that i am showing above.

I have found where others have encountered the issue and it has been handled several ways. 

  • Some suggest changing to G01 from G31. This fixes the issue but leaves the probe vulnerable to damage since an unexpected contact will be ignored. It seems to be best practice in the industry from what I have read to use G31 anytime the probe is installed to protect it.

  • I did find one post where a script was written to tie a probe contact to an E-stop input anytime the machine status wasn't "probing".  There were questions about the software handling it fast enough to do any good but that user reported success. My understanding being that the lag between the motion controller and software could be large enough to allow the crash before the software can shut down the motion controller.

  • People with an ESS note that there are options in the ESS plugin to change this behavior. I understand there to be an option that allows the machine to progress normally without a probe contact during a G31

  • I have noted that most of the weirdness goes away in the newer "touch" button probing menu but they don't cover all scenarios, namely 2 surface centering in one axis.


It is worth noting that currently there isn't even an error that happens or a message to the operator, the code just hangs and the cycle counter continues to count until i E-stop the cycle.  I had to use logging under the diagnostic tab in order to find what was happening.

I have successfully changed certain probing sequences to G01 instead of G31 by editing the script like this

original line
Code: [Select]
string.format("G%.1f Z%.4f F%.1f", ProbeCode, ZLevel, FastFeed)
edited line
Code: [Select]
string.format("G1 Z%.4f F%.1f", ZLevel, FastFeed)
It does work, but as stated above it makes me nervous about breaking the probe if i have something input incorrectly about my setup or the safeZ and probing ZLevel

All this is to ask, how would you handle this?



2
I have attached a screenshot of the Mach4 control setup of how I control my lube pump without having to script. I have since found that scripting is a good thing to learn how to do though.  It opens up a whole new world of making the screens efficient and suited to how you use your machine.

I just have the lube pump running when the machine status is enabled.  There are some other options that are more specific to cut down on pump run time if that is a concern. IE, spindle active, as Craig suggested using.
I have some relays that are built into my motion controller expansion card. 
I am able to tie an output to a pin on the motion controller and wire a 120vac control circuit into the corresponding relay.
If you don't have any integrated relays, you would just need to add a relay controlled by the output pin you select on your controller.

I haven't tackled the low lube oil switch input that needs to go back into Mach4 yet though.  I'm not sure the best way to monitor its status without bogging more important things down.I believe it will involve assigning an input pin to a signal number. Then if i understand correctly there is a function to monitor for a change in signal state that i can incorporate somewhere as an alert or flashing light or feed hold or something.

3
Mach4 General Discussion / Re: Mach4 Boss Probing Not Working
« on: November 24, 2021, 09:54:55 AM »
Hello,
To anyone reading this post.
We're changing the way that we probe in MACH4. However don't worry the traditional moves will work and nothing is being fundamentally changed.
Probing has been plagued with issues for as long as I've been at NFS (99% of the time the issue being electrical noise...) and I'm rebuilding the programming behind our probing screen and making it a much more guided experience. This will avoid any confusion as to what is happening, moving forward you will select the operation you'd like preformed and then it will walk you through the process the whole time reporting all values that need to be retained into pound vars, this way we can easily troubleshoot what's happening behind the scenes (along with the logging window).
We tried to make a experience where you enter the values and hit start and then the machine does it's thing, however we find that users with issues don't know what part of the process isn't working properly. For instance, is the machine not doing what it's told or is it a noise issue etc.
This is being worked on and it's programmed for the most part and the GUI is being designed very shortly.
All in all this sums up to me saying, we will have a better user experience for probing soon and hopefully it will allow us and our users to diagnose the issues at hand much faster as you will know exactly what's happening every step of the way.
Sorry this has been an issue :)

As someone who has been trying to climb the learning curve of understanding how to modify the current probing scripts, this sounds pretty exciting. 
What sort of timeline is this project on? I know things don't happen overnight, but I am interested!
Thank you!

4
Hello,
I have been trying to work out an issue when probing on my CNC mill. I have found that for preparatory moves where I want to use G31 in case the probe does make contact, but I'm not actually looking for a probe contact, Mach 4 is hanging. 

I originally found this issue when trying to use the 2 Surface Outside Centering script on the probing screen. In trying to troubleshoot my problem, i found that the same issue occurs on a very simple G31 MDI input when the probe is not triggered/contacted.

I'm not sure I understand the log correctly of who's/what's fault it is. I have included it below. 

When using G31 in the simplest sense, it works great. IE, machine starts to move, and it stops when the probe is triggered. 

When using G31 as a prep move where no probe contact happens is when the software is hanging on me.

Here is the error I see when I input the following in MDI, it is worth noting that the machine moves to the position X -1.000 correctly but the code hangs after the move.

G31 X-1.000 F20

Code: [Select]
2021-11-24 05:26:29.134 - API: mcCntlMdiExecute(inst = 0, commands = 'g31 x-1.000 F20') (unknown caller)
2021-11-24 05:26:29.243 - Attempt transition from "Idle" on event "MDI Start" controller.cpp:2364
2021-11-24 05:26:29.243 - Signal id 1127, (Jog Enabled), changed from HIGH to LOW.
2021-11-24 05:26:29.243 - S_IDLE_on_exit
2021-11-24 05:26:29.243 - Signal id 1172, (Machine Idle), changed from HIGH to LOW.
2021-11-24 05:26:29.243 - ACTION_start_mdi
2021-11-24 05:26:29.243 - SoftSync()! Clearing planner.
2021-11-24 05:26:29.274 - S_MDI_RUNNING_on_entry
2021-11-24 05:26:29.274 - SoftSync()! Clearing planner. stateinterface.cpp:1351
2021-11-24 05:26:29.274 - S_MDI_RUNNING2_on_entry
2021-11-24 05:26:29.274 - Signal id 1114, (Gcode Running), changed from LOW to HIGH.
2021-11-24 05:26:29.274 - Attempt transition from "MDI Running" on event "Probe" runcanon.cpp:536
2021-11-24 05:26:29.274 - S_MDI_RUNNING2_on_exit
2021-11-24 05:26:29.274 - Signal id 1114, (Gcode Running), changed from HIGH to LOW.
2021-11-24 05:26:29.274 - ACTION_start_probe
2021-11-24 05:26:29.274 - S_MDI_PROBING_on_entry
2021-11-24 05:26:29.274 - Signal id 1173, (Machine Probing), changed from LOW to HIGH.
2021-11-24 05:26:29.274 - Probing: Waiting on exit event... runcanon.cpp:267
2021-11-24 05:26:29.274 - Waiting on planner to drain before waiting on SetStill... runcanon.cpp:92
2021-11-24 05:26:31.383 - Waiting on SetStill...
2021-11-24 05:26:31.383 - Signal id 1180, (Feed Hold Disabled), changed from LOW to HIGH.
2021-11-24 05:26:31.383 - Controller::RunCanonBuffer called AddStopReportRequest() runcanon.cpp:101
2021-11-24 05:26:31.383 - Requesting a stopped report for axis 0 motors.
2021-11-24 05:26:31.383 - Requesting a stopped report for motor 0.
2021-11-24 05:26:31.383 - Requesting a stopped report for axis 1 motors.
2021-11-24 05:26:31.383 - Requesting a stopped report for motor 1.
2021-11-24 05:26:31.383 - Requesting a stopped report for axis 2 motors.
2021-11-24 05:26:31.383 - Requesting a stopped report for motor 2.

It just hangs here after the log line    Controller::RunCanonBuffer called AddStopReportRequest() runcanon.cpp:101
In case it is helpful, the machine just sits like this with the cycle time counting up until i toggle the enable button off.  The log file then continues as below

Code: [Select]
2021-11-24 05:28:33.223 - API: mcCntlEnable(inst = 0, FALSE) (Mach4GUI Button)
2021-11-24 05:28:33.239 - Signal id 1018, (Enable #0), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - Signal id 1019, (Enable #1), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - Signal id 1020, (Enable #2), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - Attempt transition from "Probing" on event "Stop" controller.cpp:5235
2021-11-24 05:28:33.239 - S_FILE_PROBING_on_exit
2021-11-24 05:28:33.239 - Signal id 1173, (Machine Probing), changed from HIGH to LOW.
2021-11-24 05:28:33.239 - S_MDI_RUNNING_on_exit
2021-11-24 05:28:33.239 - ACTION_stop
2021-11-24 05:28:33.348 - S_IDLE_on_entry
2021-11-24 05:28:33.364 - Signal id 1172, (Machine Idle), changed from LOW to HIGH.
2021-11-24 05:28:33.364 - Waiting on SetStill is Done!
2021-11-24 05:28:33.364 - Signal id 1120, (Machine Enabled), changed from HIGH to LOW.
2021-11-24 05:28:33.364 - Probing: Exiting probe state because of end of move. gcodeexec.cpp:1552
2021-11-24 05:28:33.364 - Attempt transition from "Idle" on event "Probe Complete" gcodeexec.cpp:1574
2021-11-24 05:28:33.364 - Can't transition from "Idle" on event "Probe Complete" gcodeexec.cpp:1574
2021-11-24 05:28:33.379 - Signal id 1180, (Feed Hold Disabled), changed from HIGH to LOW.

For background, at the risk of making this post too long to be interesting, my probe is hooked up to Port 2 pin 5 of the AXBB-E. It is an NPN switching probe @5volts.  I have its output hooked up to i5- and 5VDC going to i5+.  I have it set up as active low in Mach4 config. It works perfectly and is very consistent.  I'm quite certain i don't have a hardware issue, but i wanted to give that context in case it mattered.

I have the most current AXBB-E plugin that i can find. It is listed as V 1.002 in Mach4.

If anyone has any ideas about how i can resolve this please let me know.

I have posted this over on CNCdrive's forum as well on the suspicion that it is a plugin issue but i wanted to ask here as well since i am uncertain. It is also quite possible that it is my fault. I'm hoping someone can point me in the right direction.

I found one other forum post there of another person struggling with this specific issue and Mach4 but it was over a year ago and they never got any replies to their post. https://www.forum.cncdrive.com/viewtopic.php?f=22&t=2600

I also read here on MachSupport about something similar happening to people with another vendors product (Ethernet Smooth Stepper), and they added functionality to their plug in to prevent it hanging in this situation from what i understand. I only include this for context of me suspecting it as a bug.

I have attached my Mach4 logfile and my ini files in case they are useful.

Please let me know if there is other information i can provide that would be helpful and i will get it to you. 

Thanks in advance for any help or clarity you can provide!

5
Thank you for taking the time to write out this reply. I apologize for taking so long to get back to you.  I did heed your advice and stopped trying to use the embedded GPIOs on my computer.  I streamlined my in/outputs and got by with and expansion card for my AXBB-E.  I had gotten an M26X expansion board from cnc4pc and it seems to suit my needs. 
I had considered switching to an ESS at the time, and now i kind of wish i had.  I am struggling with a probing issue that I just posted about.  I can find forum posts where people encountered the same issue with an ESS and it was fixed several years ago by warp9 in their plugin.

Here is a recent one that references settings in the ESS plugin that fixed their problem https://www.machsupport.com/forum/index.php?topic=45273.0

In spite of few problems Ive had, it has been extremely fun to get my old Bridgeport S2 Boss6 CNC up and running better than it ever has.

6
Hello,
I could use some help understanding what I dont know in order to learn more about it.

I have the start of a working Mach4 setup with an AXBB-E motion controller on a Bridgeport Boss CNC mill that I retrofitted. I still need to polish the installation some more.


I am migrating from my laptop to a dedicated computer for the mill.  I bought a Dell PC 5000 embedded computer.

The new computer has 16 GPIO (general purpose in/outputs) built into it.  I am short on inputs and I am hopeful that these are usable.

The Dell manual lists the pin mapping to CPU I/O addresses

I have searched thru this forum and the Mach4 scripting manual but haven't deciphered enough to understand what i might need to do to use these as additional in and outputs to Mach4. I read thru the scripting section on the signal library. It mentions that signals can be tied to external in/outs but it doesn't get into the logistics of adding new ones.  I have started looking at LUA scripting and Modbus, but I don't know if I'm barking up the right tree.

I don't understand the steps involved in this endeavor, and Id appreciate any guidance on what i need to learn more about to pull this off if it is feasible.

Id also be happy to hear opinions related to the matter.

Quote
Embedded Box PC 5000 GPIO module In/Out mapping
The GPIOs ports on the Embedded Box PC and Nuvoton NCT6793D uses index/data pair of CPU I/O addresses 2Eh/2Fh to access NCT6793D.
GPIO 8 Out pin# to NCT6793D pin# map:

0 to 121 (GP00)

1 to 122 (GP01)

2 to 123 (GP02)

3 to 2 (GP03)

4 to 3 (GP04)

5 to 4 (GP05)

6 to 5 (GP06)

7 to 6 (GP07)

8 is GND
GPIO 8 In pin# to NCT6793D pin# map:

0 to 50 (GP60)

1 to 49 (GP61)

2 to 48 (GP62)

3 to 47 (GP63)

4 to 45 (GP64)

5 to 44 (GP65)

6 to 43 (GP66)

7 to 42 (GP67)

8 is GND

7
I already sorted this out for myself, but i am adding my issue for others in the future since this thread came up when i was searching for answers. 

If your profile name has a space in it, you need to enclose it with quotation marks or it only recognizes the first word and tries to load a non existent profile.

Example- My custom profile is named Boss CNC.  The shortcut path that worked for me is    C:\Mach4Hobby\Mach4GUI.exe /p "Boss CNC"

I just experimented until i found something that worked. Perhaps this would be common sense to most users, but I wanted to document it just in case.

Thanks!

Pages: 1