Hello Guest it is April 24, 2024, 08:38:35 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 - mhackney

Pages: « 1 2 3 4 5 6 7 »
11
Yes I am absolutely positive! I'll shoot a quick video of the behavior this evening.

And, if I clear the G54 row ( to 0s) in the fixture table before calling Reference All Axes, the move does not take place.

If I then jog to position on my workpiece and click the Zero axis buttons with the fixture table open, I see the G54's axis immediately updated with the offset. Then, doing another Reference All Axes will home and now move to that "fixture" location.

12
I'll verify this later but I am fairly certain that after I click Reference All Axes (Home) that it displays the message "Referencing is complete" before moving to the table offset location.

13
Bill_O thanks. I had looked at the load script RefAllHome and it is not calling G54. Here is the code:
Code: [Select]
-- Ref All Home() function.
---------------------------------------------------------------
function RefAllHome()
    mc.mcAxisDerefAll(inst)  --Just to turn off all ref leds
    mc.mcAxisHomeAll(inst)
    coroutine.yield() --yield coroutine so we can do the following after motion stops
    ----See ref all home button and plc script for coroutine.create and coroutine.resume
    wx.wxMessageBox('Referencing is complete')
end

I'm trying to track down mc.mcAxisHomeAll to see if there is something there but haven't found it yet.

14
Ack, searching the entire mach directory did not get any other hits for modal or modal gcode. So back to square one.

15
Well, I guess the this is not what the Modal Gcodes wizard does. Apparently, it reads the modal gcodes already set in the system and displays them with more detail in a nice table. Removing a row from the wizard table does not change what the modal gcodes are. But at least now I know that these are called modal gcodes so I can continue searching for that.

16
While exploring the Screen Editor I found where these gcodes are defined. I didn't realize that the line that shows these gcodes is dedicated to that task and the field on the screen is called Modal Gcodes. I then googled Modal Gcodes and learned that these are in the ModalWizard. I opened ModalWizard.mcs in an editor and sure enough, there they are:

Code: [Select]
local groupNames = {
"01: Feed mode",
"02: Plane selection",
"03: Absolute or incremental",
"04: Arc center mode",
"05: Feed rate mode",
"06: Units",
"07: Cutter compensation state",
"08: Height offset state",
"09: Active canned cycle",
"10: Retract Z level selection",
"11: Scale mode",
"12: Modal macro",
"13: Spindle mode",
"14: Active coordinate system",
"15: Cutting mode",
"16: Coordinate system rotation mode",
"17: Polar mode",
"18: Compensation mode"
}

This is the ordered list and item 14 is the one that inserts the G54. Is it safe to edit this macro? Is it as "easy as" removing row 14 and renumbering the other rows?

17
I'm a 15+ year long Mach3 user on 2 CNC mills and now bringing up a router with Mach4. This issue is driving me crazy and is behavior I have not seen on mach3. Let me describe my workflow, then the behavior followed by what I've done to diagnose/solve the issue.

I'm on Mach4 build 4612, using the WxRouter.set screen.

I have a simple 3 axes router with home switches and soft limits enabled.

The way I like to work is this:

Home (Reference All Axes (hom) the machine after I turn everything on to make some cuts.
Clamp my work piece to my bed. I typically make onsies or twosies
Jog to the datum on the work piece and touch off the tool old-school using rolling paper
Zero X, Zero Y, Zero Z

Now I load and run my gcode.

Observed Behavior:
(unless I zero out the G54 section of the View->Fixture Offsets... table)

When I do the Reference All Axes (home) the machine homes as it should, I see the DROs turn green and set to "0" but then the machine immediately moves to the position set in the G54 of the Fixture Offsets table. I do NOT want this behavior. Many times, after the first job, I jog the tool out of the way to move my work and setup for another job. This new job will likely be in a different location on my router's bed and may be a thicker workpiece. Once I have the new workpiece clamped, I do another Reference All Axes (home) and expect the tool to stay at 0,0,0 so I can then jog to the new datum Zero the axes, load the gcode and run. But, it goes to the fixture offset and that might cause a crash into the material or a clamp.

I've used the above workflow on my milling machine for 15+ years and have never had an issue. I've never used fixture offsets and don't really have a need. If I zero out the G54 row of the fixture offset before homing, I get the expected behavior.

What I've done to Diagnose:
I notice when I launch Mach4 that the status line shows a string of gcodes that includes G54. In my case that line is:

G0 G17 G90 G91.1 G94 G20 G40 G49 G80 G50 G67 G97 G54 G64 G69 G15 G40.1

So I thought the logical thing to do is remove the G54, but I can't find where this string is created! I've looked at the load screen script, the Ref All Axes button scripts, etc. I've also looked at the Mach Config dialog and don't see where G54 is added. I've also looked at the Probing and Offsets tabs on the screen and don't see anything that can help.

My ideal scenario would be to have the workflow that I've used for 15 years. But, if there is an alternative workflow that works with this automatic fixture offset I'd consider changing if there were advantages.

thanks!


18
I don't like throwing new parts at a problem but I have no idea on additional tests, diagnostics are re-wiring I can do to resolve this issue.

I am now down to a minimally configured G540. Shielded wires (with proper shield grounding to the steppers) and no other connections other than power in the control box - which is an aluminum box and the enable pin to an e-stop (and I did test jumpering this to eliminate noise from the switch and wiring). The power supply is a quality 48V Mean Well (I use these on all my CNC machines).  That's it, no other wiring in the box. The PMDX-411 is connected to the G540 outside the box and the USB cable runs to the laptop. I suppose I could go full-monty and wrap the USB cable with copper foil and ground it - DIY shielding - but I am not convinced that will help.

So, with this configuration, I can jog. I can't home of course since no home switches are connected. I do not have the probe physically connected but I do have it configured in M4 and the 411. So, in theory, a G31 command should at least make the Z move. But it does not, M4 screen shows the odd dimming and then just sort of hangs. It is still responsive but I have to click the reset button to get control back. And then about 1/2 the time, this causes the 411 to disconnect.

I agree with Bill about USB, suboptimal for sure. But I'd really like to leverage the G540 and the control box I've already built (and had working for several years). The ESS is compelling but I don't need support for multiple parallel ports. I searched and didn't find a simpler, 1 parallel port equivalent. Maybe someone here has come across one? That would be ideal to convert an existing simple G540 based system to ethernet interface.

19
The spurious signal is gone now actually - after rewiring it and adding a capacitor filter. At least I do not see the led probe flicker now but the behavior in Mach is the same. G31 and the probe macros all basically hang with no meaningful info in the logs.

I've whittled down to the very simplest setup I can imagine now. I realized I could disconnect all home switches and probe wiring and simply have the steppers wired. Then keep the probe software configuration without an actual probe attached (since it is NO). But this fails in the same way also. So this simple setup consist of the G540, wired to a 48V power supply 6" away all in an aluminum case. Then, on the outside of the case, on the front panel of the G540 are the three DB9 connectors to the steppers and the DB25 connected directly to the PMDX-411, which is connected to the USB port on my computer.

I'd consider moving to something else but there really aren't that many options without throwing a lot of money at it. My lathe has an Acorn controller with ethernet primarily because I built that machine after PCs with parallel ports became hard to find and modern OS's won't run on them.

20
I don't know how a bad connection or noise can be the culprit with the "completely detach the probe" experiment I just described. Unless a bad connection on one of the other ports would/could crossover to the vacant probe port? And 1) probing works fine in Mach3 and 2) prior to adding the probe, everything else worked fine in Mach4. That's why I'm perplexed. The PMDX-411 connects directly to the G540 so there is no ribbon. It in turn connects to the PC USB port.

Pages: « 1 2 3 4 5 6 7 »