Hey All,
Just got the note a few minutes ago, new PP version 2.3.4 released. Seems to have some nice improvements for probing and tapping.
Terry
Hey All,
Just got the note a few minutes ago, new PP version 2.3.4 released. Seems to have some nice improvements for probing and tapping.
Terry
And the G54 Pxxx extension to allow 500 work offsets.
Was just thinking it had been a few months and wondered when new update would be out.
Well I checked out the probe tip diameter routine today, and so far I'm disappointed and puzzled.
The way it works is you run the probe inside a know diameter bore after inputting the diameter into a dro. Machine then runs a routine and reports, and records the apparent tip diameter.
I have two precision gauge rings, one is 1.06348", the other is 1.1107".
Running the routine on the 1.1107 bore came up with a tip diameter of 0.1944", very close to the previously stored value of 0.1948". But running the routine on the 1.06348 bore yielded 0.2144", to my mind quite a difference.
Ran each on several times with identical results..
I haven't called tormach yet because I want to check a few things, such as verifying the tip hasn't any runout and double check that I ran each of the gauges with the same Z height, etc.
I'm going to recheck in the morning, then if no change call tormach, of course that will have to wait for Monday. LoL
Terry
What is this line in read me file?
We added support for xsTECHrouter bench-top router.(PP-2593)
Well, this morning I got to reach into my closet and dust off my dumba** hat. Lol
The new probe tip calibration routine works just fine if you remember to reset the DRO to the correct ring diameter after you switch test rings.
Sorry for the false alarm yesterday.
Terry
I had the probing started up slow today on a fresh day. Upon restart, it loaded up the probing feed rate in imperial values for my metric setup. This could possibly be a bug.
So, I wasn't going to bring this up, after my probe calibration routine embarrassment, until I Talked to Tormach.
But, after Snecx's comment about probing I decided to let everyone know about another problem I found.
It's a little weird, so stay with me.......LoL
When probing with a Tormach active digital probe, close to the table, I get an error message when trying to probe Z and set the origin. The message is "G38.2 move finished without making contact". The part that is weird is it only happens when the probe tip starts around 1.5" from the surface of the mill table, or lower. Any higher, and the probing works fine. When low enough to get the error, X and Y probing work fine.
I generally work from a vice about 90% of the time, but this time was working on a plate the is only 1/2" thick. Since I rarely do this, I wondered if the issue was with 2.3.4, or maybe in an earlier version, so I re-loaded version 2.2.4, and everything worked just fine.
So, thinking perhaps a bad upgrade, I re-loaded 2.3.4, and the problem returned.
So right now, I'm stumped, if anyone has a suggestion, I'd love to hear it. Otherwise, I'm staying on v2.2.4, until I talk to Tormach.
So I recommend caution when probing if you have gone to v2.3.4, with 2 people experiencing strange behavior, there is a possibility that something is off with the probing routines in v2.3.4.
Terry
Again, nothing for the lathe, been asking for a part counter DRO for at least 2 years and it would be really cool if they could add a DXF import.
At least you can now queue the Ref Z and Ref X buttons in lathe like you always could in mill.
For a part counter have you considered using a global named parameter? It's not as nice as a dedicated DRO but better than nothing. The example below prints to the Status tab but doesn't yank the Status tab up. Press and hold F1 to see it. Release F1 to go back to the Main tab.
Parameter names starting with underscore stick around across program runs and are accessible to all G code programs and subroutines.
In the MDI line set it to zero:
#<_part_counter> = 0
In the G code:
(increment _part_counter after a completed cycle)
#<_part_counter> = [#<_part_counter> + 1]
(print current value of _part_counter on the Status tab)
(DEBUG,Current value of _part_counter is: #<_part_counter>)
I wanted to follow up on my earlier post about the Z probing anomaly I mentioned in my last post about v2.3.4'
Tormach has confirmed that they have identified a bug in the probing routine and that there will be a fix in the next upgrade.
Just remember to be cautious if you use v2.3.4 and do any probing.
Terry
I'm not good enough to play with parameters like you are able to.
I'm using an external digital counter since I have no choice but, these can't be programmed, they just count ( do this with the USB relay board)
all I want is a simple DRO like X and Z axis, probably smaller and I could input a value in it and it can count parts
Thanks for the reply
I'm trying to update some old programs prior to installing 2.3.4. Does anyone know how to determine which offset is in effect when using the G54 Pxxx extension? In previous versions #5220 contains the coordinate system number and #5221-#5390 contain the offsets. How are things stored, for example, after G54 P123?
#5220 still holds the current WCS number, 1-499. The first 9 WCS still function like they always have and live in #5221-#5390. To get the offsets for a WCS > 9 switch to that WCS with G54.1 Pxxx and read them from global named parameters. #<_work_offset_x>, #<_work_offset_y>, #<_work_offset_z>, and so on.
G53 positions are available via #<_x_machine>, #<_y_machine> and the like.
Thanks!
I wish that this and stuff like U_TPI and U_inch were documented somewhere.
2.4.0 has automatic parts counters with a lot of flexibility. Check it out.
There is mention of G37.x in the release notes and that the documentation is in the newest operator's manual but there is no mention in the manual at https://www.tormach.com/support/wpdm...ual-0916a-web/ Any suggestions for where to find the appropriate manual for G37 information?
I see G37 info in the 770M Operator's Manual. Section 10.2.11
https://www.tormach.com/support/wpdm...erator-manual/