Units mismatch at startup, v2.10

[Joseph Poirier]

Hi all, there was another patch that went in 2015.4/22.

1 Virtual Borders are now working correctly in Inches.
2 The display crosshairs now follow the virtual collection.

[KevinO]

Joseph,
The first time I used V2.1 Build 14 this morning, with the first file I loaded the router took off like a bat out of hell and crashed into a clamp breaking my 0.062 bit before I could hit the Emergency button.

Will this latest patch fix that? Is that what you meant by "Virtual borders are now working correctly in inches."?

After I shut everything down and restarted the software, I noticed that all of the saved virtual coordinates were mm instead of the inches I had set in preferences (that is, first saved x-coordinate was 152.4 instead of 6 inches). I think the machine read the 152.4 as 152.4 inches and was heading in that direction when it hit my clamp.
Kevin

[KevinO]

Joseph,
Look at the attached picture from the release of today (you still call it Build 14 even though you made changes) . It confirms what I said in the previous post. You still don't have mm and inches sorted out. The picture shows the saved Virtual collection points and they are all in mm not inches even though I have preferences set to inches. Look in the virtual panel. See the first point (x=-5.000, y=-3.5)? Those are inches. Now look in the Preferences box. See Reading 1 (x=-127.000, y= -88.9000)? Those are in mm, even though I have Preferences set to inches.
I believe that's what caused my gantry to take off and smash into the clamp. The program is reading the the first point of -5.0 inches, converting it to -127.00 mm, but then driving the gantry to -127 inches!!
Note that the runaway only happens when Preferences are set to "Image Cutting Area" and not "Material Edge"

Please fix this and release it as V2.1 Build 15, or any other new number so I'll know it's been fixed.

Thanks.
Kevin

[monitoringpost]

I've found a different bug and have let Joseph know but I thought I'd post it here as I think it could be a serious issue. I also don't like the versioning not being changed. Anyways the bug is user preferences being overwritten for touch plate thickness and safe Z height. It's repeatable and here's how you can replicate what I'm seeing.

First change the preferences for Touch Plate thickness and Safe Z to something different than the defaults of .374" and 0.53" respectively. We're just doing a test here we're not cutting anything. Also, click the button to zero all your axis - this will make it easier to see the bug. Load any G-Code.

-Answer 'NO' to the pop-up "Do you want to setup this file using Virtual Zero" upon file loading.
-Click the 'RUN' button
-The Touch Plate screen then opens
-Click 'CANCEL'
-Your Z axis like mine should now raise to the safe Z height but not what you entered but the default of 0.53". And, if you check preferences you'll see that your T.P. thickness has been overwritten with the default along with safe Z height.

[EdThorne]

Hi Kevin and Joe,

I read Kevin's post and tried to recreate the issue.

I loaded the latest version and it still says "V2.1 build 14" so I don't know if this is actually the same version as the previous that I had loaded.

I first cleared the virtual table by pressing the "Clear Reading" button under the "Virtual" tab for "Preferences."

I then loaded a TAP file created in inches with Virtual Zero enabled. The controller moved properly to the edges [offset by 1"] and stored the correct values at each of the five locations.

I then looked at the "Saved Virtual Readings" under the "Virtual" tab for "Preferences." This is confusing. See the attached screen shot and notice that each "Saved Virtual Reading" is expressed in mm and not inches.

I then pressed "Run File" and the CNC ran properly in inches and the mm values did not interfere.

I exited the SCP and restarted the program. I loaded the same TAP file while enabling the existing virtual values. I zeroed the z-axis and ran the file. It again ran properly. I did observe that the "Saved Virtual Readings" were still in mm but the system didn't seem to be affected by this. It would be nice to see the "Saved Virtual Readings" displayed in the same units that have been selected but I couldn't duplicate the run-away problem that was observed. I therefore suspect that the run-away router may not be related to the "Saved Virtual Readings" that we both noticed are not as we would like to see them.

I am using Aspire 8.013 but this may not have anything to do with the reported issue. My Post-processor is "CNCShark-USB_NewArcs_inch.pp". Kevin could you send along your TAP file for me to try?

Best,
Ed

UPDATE: The material size here is 7" by 7".

[Rando]

I had a couple runaway jog moves on the latest build 14, but they were few and I haven't had any in a couple days. Fingers crossed, but wary.

OTOH, I have had zero card corruptions or ncPodGCodeCompiler (?) hangs, and indeed no failed loads. So that's a Martha Stewart-approved Good Thing(TM).

[KevinO]

Ed,
Please run your test one more time only this time in Preferences set "Image Cutting Area" instead of "Material Edge". That's when the runaway occurs. Note, keep your other hand on the Emergency Stop button when clicking Run, this is not for the faint of heart!
Craig,
I also have the bug you described.

Regards,
Kevin

[EdThorne]

Hi Kevin,

Okay, I changed to using "Image cutting edge" but everything ran okay. I exited the program and restarted using stored Virtual positions and it again ran correctly. Hmmm, sorry but I haven't been able to reproduce the problem. I am attaching a screenshot and my TAP file just to see if you get the same results running my file.

Regards,
Ed

[EdThorne]

I should add that changing between material edge and cutting area and subsequently loading a tap file using Virtual Zero correctly forces the operator to rerun virtual setup. This seems proper to me as the offset positions have changed.
Ed

[KevinO]

Odd that my problem couldn't be reproduced. I am attaching the file that is repeatably causing the gantry to runaway using V2.1 Build 15 (latest 15) with Preferences set to "Image Cutting Area". Maybe my file is corrupted, although I did re-create the file after the first runaway with the same results.
Ed, perhaps you or anyone else could try to run it and let me know your results. BTW, I rolled back to V2.01 and the file worked perfectly.
Thanks.
Kevin