Hello Guest it is April 25, 2024, 02:22:52 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 - funkenjaeger

Pages: 1
1
Mach4 General Discussion / Re: Problem with spindle RPM DRO
« on: January 29, 2023, 01:27:31 PM »
May I ask what the workaround/fix did you get?
The workaround I had some success with at the time was the one provided in the linked warp9td forum thread.  I don't know whether it's since been rolled into the released ESS plugin.

For me, the actual "fix" was to switch from Mach4+ESS to LinuxCNC+Mesa.  I liked Mach4 and the ESS for the most part, but since I switched I've never had to wait for a vendor/developer to fix anything for me.

2
Mach4 General Discussion / Re: Setting zero positions for G30
« on: November 16, 2021, 09:19:32 PM »
As the original poster from 4 years ago, I have to say that it's a bit of a sad state of affairs that this is still something that warrants reverse-engineering of Mach4 today...  :P

3
Mach4 General Discussion / Re: Problem with spindle RPM DRO
« on: April 17, 2020, 12:18:25 PM »
Another update:  After further testing, the issue actually wasn't resolved by updating to the aforementioned versions of Mach4 and the ESS plugin.

I posted to the Warp9TD forums - the behavior was confirmed, workarounds provided, and a solution should be coming to a released plugin soon!
https://warp9td.com/index.php/kunena/7-general-discussion/8384-ess-always-updating-spindle-sensor-rpm-in-mach4#24339
I've tested the development build that Andy provided and it successfully resolves this issue.

4
Mach4 General Discussion / Re: Problem with spindle RPM DRO
« on: April 14, 2020, 10:25:42 PM »
Update:  Immediately after posting I started to wonder whether some other plugin was writing to the Sensor RPM, causing a race condition in the DRO.  The only obvious suspect was the Ethernet Smoothstepper plugin, so I unplugged the ESS board and voila - the "Spindle True RPM" DRO started working just fine.  So it seems that the ESS plugin was causing the problem, not Mach4 itself.

I checked the ESS plugin change log and it turns out that the latest few updates from earlier this year contained some changes related to spindle RPM.  I updated to ESS plugin v256, also requiring a Mach4 update for compatibility (I went to the latest, v4469) - and now the Spindle True RPM DRO works fine even with the ESS connected, so the underlying issue seems to have been resolved in the latest version of one or the other.

Hope this can help others.

5
Mach4 General Discussion / Re: Problem with spindle RPM DRO
« on: April 14, 2020, 09:58:12 PM »
Bumping this thread because I ran into exactly the same issue as the OP.  A DRO set to DRO Code "Spindle True RPM" just flashes erratically between 0 and the real RPM at a high rate.  Looking in Register Diagnostics, the value coming back on modbus is nice and stable. 

As a test, I did the following in the PLC script:
Code: [Select]
rc = mc.mcSpindleSetSensorRPM(inst,freq*60/100)
RPM, rc = mc.mcSpindleGetSensorRPM(inst)
scr.SetProperty('droTestRpm','Value',tostring(RPM))
I set the sensor RPM using the frequency read from the VFD, and then immediately read the sensor RPM back and use it to set the value of another DRO (which has no "DRO Code" selected).  That DRO works fine, nice and stable, no flickering.  This seems to support OP's theory that something in the background is erroneously stomping on the "Spindle True RPM" DRO.

Technically the test code above is a usable workaround for this issue, but it is a bit of a hack - it would be nice to understand what's really wrong here.

6
Mach4 General Discussion / Re: Shuttlepro looses button assignments
« on: January 27, 2020, 07:50:53 AM »
This issue has plagued me as well, for as long as I can remember.
I'm concerned about whether there are any other settings getting lost from Machine.ini that aren't as immediately noticeable...

7
Thanks Craig - that's very useful insight into how Mach works under the hood.  I just watched Daz's video and now I understand the coroutine concept; I'll have to do some digging in the existing code to figure out how to apply it in this case.

8
So I've done some searching and seen threads such as this one, and I'm aware that dazthegaz has put together a nice M6 macro for automated tool probing.
I really like the idea of daz's automated approach, but it does require having a touch plate/tool setter at a fixed location on the machine.  I am working on setting up that sort of arrangement on my machine, however since I use a dust boot which is manually set to a fixed height based on stock thickness (and is independent of Z travel) I have a lot more interference concerns so it's going to take some work to implement it in a way that doesn't lead to a high risk of crashes.

So, in the meantime I've been experimenting with trying to enable manual Z probing using a touch plate while the machine is paused due to an M6 command.  I have determined that in that case, the machine state is "File Macro Hold".  I added a button on the main panel which does a G31 operation to probe Z, and it works fine when the machine is in the 'idle' state - and the button is set to be enabled in the 'file macro hold' state also.  However, when in 'file macro hold', the probe operation simply doesn't happen.  I'm allowed to jog the machine so clearly motion is not disabled outright, but it seems like it's refusing to execute the G31 command.  Is that behavior something I can change?  Or is there a fundamental limitation that prevents G-code commands from being executed while in the "file macro hold" state?

I understand that the usual answer to this is to postprocess to separate G-code files, each using only a single tool - and that has been my work flow so far.  However, I often find myself doing anywhere from 2 to 5 tool changes to make a given part, and I feel it would be much more convenient and less prone to error (changing to wrong tool, forgetting to load the next file or loading the wrong one, etc) if I could keep everything consolidated and use M6.

Any advice appreciated!

9
Mach4 General Discussion / Setting zero positions for G30
« on: November 12, 2017, 11:16:28 AM »
I've been trying to use G30, but it seems that no matter what I do, it always goes to machine zero (same as G28).

The Mach4 Mill GCode manual says that the #Variables for the P2 position are #5301, #5302 and #5303 (X, Y and Z respectively).  I've set those to what I want, both using MDI and using the register tool under diagnostics, to no effect.
I found what seems like a red flag, in that when I open up the Fixture Offsets window, the values I set for #5301-#5303 are showing up in the row for G58 fixture offset.
This suggests to me that these may not be the correct addresses.  Is it possible that the manual is out of date with respect to these addresses, or am I missing something?

I'm running a pretty fresh installation of Mach4 Hobby (within the last couple of weeks), 4.2.0.3481.

Pages: 1