Units mismatch at startup, v2.10

Discussion/questions about software used with your CNC Shark and programming issues

Moderators: al wolford, sbk, Bob, Kayvon

Rando
Posts: 757
Joined: Tue Jan 06, 2015 3:24 pm
Location: Boise, ID
Contact:

Units mismatch at startup, v2.10

Post by Rando »

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.
Are YOU gonna press that home button? You SEE that X-value? Yeah, that WAS millimeters...not so much now!
Are YOU gonna press that home button? You SEE that X-value? Yeah, that WAS millimeters...not so much now!
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)

Joseph Poirier
Posts: 107
Joined: Fri Nov 08, 2013 10:03 am
Location: Toledo, Ohio
Contact:

Re: Units mismatch at startup, v2.10

Post by Joseph Poirier »

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.

Rando
Posts: 757
Joined: Tue Jan 06, 2015 3:24 pm
Location: Boise, ID
Contact:

Re: Units mismatch at startup, v2.10

Post by Rando »

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 :D. 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)

KevinO
Posts: 67
Joined: Mon Feb 27, 2012 7:25 pm
Location: Long Island, New York

Re: Units mismatch at startup, v2.10

Post by KevinO »

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

Joseph Poirier
Posts: 107
Joined: Fri Nov 08, 2013 10:03 am
Location: Toledo, Ohio
Contact:

Re: Units mismatch at startup, v2.10

Post by Joseph Poirier »

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.
Last edited by Joseph Poirier on Mon Apr 27, 2015 2:18 pm, edited 1 time in total.

EdThorne
Posts: 345
Joined: Mon Nov 26, 2012 11:26 pm
Location: Massachusetts

Re: Units mismatch at startup, v2.10

Post by EdThorne »

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.
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.
Best regards,
Ed

KevinO
Posts: 67
Joined: Mon Feb 27, 2012 7:25 pm
Location: Long Island, New York

Re: Units mismatch at startup, v2.10

Post by KevinO »

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
Attachments
V2.1 Rel 10 Virtual.jpg

Joseph Poirier
Posts: 107
Joined: Fri Nov 08, 2013 10:03 am
Location: Toledo, Ohio
Contact:

Re: Units mismatch at startup, v2.10

Post by Joseph Poirier »

check [Preferences] [Virtual Cut Depth Offset] set it to 0.0

KevinO
Posts: 67
Joined: Mon Feb 27, 2012 7:25 pm
Location: Long Island, New York

Re: Units mismatch at startup, v2.10

Post by KevinO »

I didn't change the Virtual Offset from the default of 0.
Regards,
Kevin

EdThorne
Posts: 345
Joined: Mon Nov 26, 2012 11:26 pm
Location: Massachusetts

Re: Units mismatch at startup, v2.10

Post by EdThorne »

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

Post Reply