Units mismatch at startup, v2.10
Moderators: al wolford, sbk, Bob, Kayvon
Units mismatch at startup, v2.10
All:
I installed the newer panel version, 2.10, and am now experiencing catastrophic units-of-measure conflicts. All my toolpaths are in mm, as are the coords for 0,0,0. Say the unit is as 0,0,12 (safe height, mm). When I start the v2.10 panel, it always starts in inches regardless of preferences. So the first move to zero attempts to plunge 12 INCHES. When I look in the prefs, it shows millimeters. So I save, no change...the panel still thinks its in inches. So I set inches, save, set mm, save, no change. Always inches. Oddly, some times the jog movement is right, others not.
The only way to get it to change is to load a gcode file that's in mm. But, then the panel converts the "inch" values to mm...so 12mm gets seen as 12 INCHES, and then converted to 304.8 mm, so the problem is still there.
So, in the current, I have to somehow make sure the system is at 0,0,0 when I turn it off, otherwise risk damage. And no, I don't want to re-zero it. If the unit/software can remember the values it was using, then why doesn't it remember the units.
And, why don't you guys fix that stupid Set Coordinates dialog box to read and properly display the units? Why is it always in inches regardless of the units in operation or chosen?
I know you're not liable for damages, but this bug has already cost me two $40 end mills, damaged a $20 bar of Aluminum, and probably greatly shortened the life of the z-axis leadscrew nuts and bearings. What is going on here?
Thom
I installed the newer panel version, 2.10, and am now experiencing catastrophic units-of-measure conflicts. All my toolpaths are in mm, as are the coords for 0,0,0. Say the unit is as 0,0,12 (safe height, mm). When I start the v2.10 panel, it always starts in inches regardless of preferences. So the first move to zero attempts to plunge 12 INCHES. When I look in the prefs, it shows millimeters. So I save, no change...the panel still thinks its in inches. So I set inches, save, set mm, save, no change. Always inches. Oddly, some times the jog movement is right, others not.
The only way to get it to change is to load a gcode file that's in mm. But, then the panel converts the "inch" values to mm...so 12mm gets seen as 12 INCHES, and then converted to 304.8 mm, so the problem is still there.
So, in the current, I have to somehow make sure the system is at 0,0,0 when I turn it off, otherwise risk damage. And no, I don't want to re-zero it. If the unit/software can remember the values it was using, then why doesn't it remember the units.
And, why don't you guys fix that stupid Set Coordinates dialog box to read and properly display the units? Why is it always in inches regardless of the units in operation or chosen?
I know you're not liable for damages, but this bug has already cost me two $40 end mills, damaged a $20 bar of Aluminum, and probably greatly shortened the life of the z-axis leadscrew nuts and bearings. What is going on here?
Thom
=====================================================
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
-
- Posts: 107
- Joined: Fri Nov 08, 2013 10:03 am
- Location: Toledo, Ohio
- Contact:
Re: Units mismatch at startup, v2.10
We just revised this for the next release, so users can flip back and forth between inches and millimeters.
Previous setting was off machine operations, not preference default units.
We are in the process of testing the mm settings now.
Previous setting was off machine operations, not preference default units.
We are in the process of testing the mm settings now.
Re: Units mismatch at startup, v2.10
I can confirm that it's working much better. Thanks, Joseph, for letting me in the Beta long enough to stop trying to destroy my machine . You're a prince, man. Your help is greatly appreciated.
=====================================================
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
Re: Units mismatch at startup, v2.10
Glad to hear the mismatch issue has been resolved, but what about the problem brought up by Ed Thorne in his post (Issue with SCP 2.1 rel 003) dated Feb 28, 2015? He described a 0.010 inch offset that occurred in the z axis. I was able to confirm his problem. Will that fix be included in the revision to be released? How will the latest version be identified?
Joe Poirier, can you comment?
I am still using V2.01 Release 001 until I'm sure all of the issues with V2.1 have been resolved. Reading through all of the posts so far regarding V2.1, I have no idea what the latest official version is and what it actually fixes. This NWA Shark control software is the only software I use regularly that seems to handle updates in such a haphazard way. Sorry NWA, until I'm convinced otherwise that's the way I see it.
Kevin
Joe Poirier, can you comment?
I am still using V2.01 Release 001 until I'm sure all of the issues with V2.1 have been resolved. Reading through all of the posts so far regarding V2.1, I have no idea what the latest official version is and what it actually fixes. This NWA Shark control software is the only software I use regularly that seems to handle updates in such a haphazard way. Sorry NWA, until I'm convinced otherwise that's the way I see it.
Kevin
-
- Posts: 107
- Joined: Fri Nov 08, 2013 10:03 am
- Location: Toledo, Ohio
- Contact:
Re: Units mismatch at startup, v2.10
The latest update v2.1 Build10
resolves a number of issues including the offset.
Hats off to Thom for testing the millimeters for us, so I could debug the thing.
There were more unit conversion patches all the way through to Build15. The original issue was first noticed after Build 003
Build 16 Adds Grid lines and provides a user [Preferences] option to set the size of the space between the lines.
resolves a number of issues including the offset.
Hats off to Thom for testing the millimeters for us, so I could debug the thing.
There were more unit conversion patches all the way through to Build15. The original issue was first noticed after Build 003
Build 16 Adds Grid lines and provides a user [Preferences] option to set the size of the space between the lines.
Last edited by Joseph Poirier on Mon Apr 27, 2015 2:18 pm, edited 1 time in total.
Re: Units mismatch at startup, v2.10
Fantastic work Joe and the NWA test team. There are many features that have been fixed and/or improved. This includes the elimination of the initial move to 0,0,0 at the start of a run. Also, pressing the EStop raises the z-axis to the safe-height and moves the y and x axes to 0 positions, respectively. The 0.010" offset error that I reported in another post is fixed. The scaling on the 2D view is absolutely perfect! I haven't tried Virtual Zero yet but I will this weekend. I bet it's perfect. I can't say enough good things about your work. Your efforts are much appreciated.Joseph Poirier wrote:The latest update v2.1 Build10
resolves a number of issues including the offset.
Hats off to Thom for testing the millimeters for us, so I could debug the thing.
Best regards,
Ed
Re: Units mismatch at startup, v2.10
Joe,
I've tried out V2.1 Rel 10 and everything looks good, but I do have a question.
Please look at the attached photo. It's a screen shot of the run I used to test out the new revision. I'm running the GCode with Virtual on. Note the Virtual screen on the right. See the coordinates for the center, upper left and lower left? They are (0,0,0), (-3.000,+1.000,+0.007) and (-3.000,-1.000,+0.001). Since the (0,0,0) center is located in the middle between the two pockets shown, it seems to me that all virtual z cuts in the left pocket should be slightly less deep than the actual depth defined in the GCode based on the +0.007 to +0.001 z heights shown in the virtual screen.
However, if you look at the actual z depth shown in the coordinates screen, it shows -0.129 when the GCode is calling for -0.125. Why isn't the actual z depth more like -0.121? It seems like the virtual is increasing depth when the starting surface is higher than the origin (0,0,0), rather than reducing depth when the starting surface is higher.
Am I missing something or is Virtual compensating in the opposite direction from what it should?
Regards,
Kevin
I've tried out V2.1 Rel 10 and everything looks good, but I do have a question.
Please look at the attached photo. It's a screen shot of the run I used to test out the new revision. I'm running the GCode with Virtual on. Note the Virtual screen on the right. See the coordinates for the center, upper left and lower left? They are (0,0,0), (-3.000,+1.000,+0.007) and (-3.000,-1.000,+0.001). Since the (0,0,0) center is located in the middle between the two pockets shown, it seems to me that all virtual z cuts in the left pocket should be slightly less deep than the actual depth defined in the GCode based on the +0.007 to +0.001 z heights shown in the virtual screen.
However, if you look at the actual z depth shown in the coordinates screen, it shows -0.129 when the GCode is calling for -0.125. Why isn't the actual z depth more like -0.121? It seems like the virtual is increasing depth when the starting surface is higher than the origin (0,0,0), rather than reducing depth when the starting surface is higher.
Am I missing something or is Virtual compensating in the opposite direction from what it should?
Regards,
Kevin
-
- Posts: 107
- Joined: Fri Nov 08, 2013 10:03 am
- Location: Toledo, Ohio
- Contact:
Re: Units mismatch at startup, v2.10
check [Preferences] [Virtual Cut Depth Offset] set it to 0.0
Re: Units mismatch at startup, v2.10
I didn't change the Virtual Offset from the default of 0.
Regards,
Kevin
Regards,
Kevin
Re: Units mismatch at startup, v2.10
Hi Kevin,
I am sorry that you are experiencing problems. I tried several tests but I couldn't reproduce what you observed. I admit that the data that you presented doesn't look correct.
I placed a block on the table and raised the left side along the x-axis (when facing router). The pitch over a 3" span was about 0.33" along the x-axis. I did the virtual zero setup and removed the blocks. I then ran to cut a 3" square (except with nothing to cut) while pausing at each corner. I calculated each z-axis position and everything was essentially correct. I say essentially because it is difficult to pause at exactly the corner for each pass. The correction made by virtual zero software appeared to be correct and in the proper direction.
I wish that I could explain you observed issue. Are you running 2.1 Build 10 or 2.1 release 10? I am testing using Build 10.
Regards,
Ed
I am sorry that you are experiencing problems. I tried several tests but I couldn't reproduce what you observed. I admit that the data that you presented doesn't look correct.
I placed a block on the table and raised the left side along the x-axis (when facing router). The pitch over a 3" span was about 0.33" along the x-axis. I did the virtual zero setup and removed the blocks. I then ran to cut a 3" square (except with nothing to cut) while pausing at each corner. I calculated each z-axis position and everything was essentially correct. I say essentially because it is difficult to pause at exactly the corner for each pass. The correction made by virtual zero software appeared to be correct and in the proper direction.
I wish that I could explain you observed issue. Are you running 2.1 Build 10 or 2.1 release 10? I am testing using Build 10.
Regards,
Ed