UCCNC version 1.2103 is ready for testing.
The download link:
http://www.cncdrive.com/UCCNC/setup_1.2103.exe- Question function to accept negative numbers too. It only accepted positive numbers.
- Added some algorithm for G41/G42 gouging. This will not fix all cases and vectors opposite direction change will be added later.
- Toolpathclickevent was added to the plugininterface detecting mouse clicks on the toolpath viewer and calculating the viewer to the workspace coordinate system unprojected coordinates and sending them to the plugins.
- Detailed tooltable tool dia and lenght values are formatted to have the same number of digits as how it is setup in the UCCNC settings for other DROs.
- M98 did not run correctly in single cycle. Was broken when the G41/G42 was implemented. Fixed.
- M98 when codes with L0 which means to call it 0 times had an issue that if it was codes with a #var, e.g. M98 L#1 Pxx and if #1 was 0 on g-code loading time then the line was not interpreted which was a problem, because if later #1 changed a value to other than 0 then this line still did not execute. Now the line is interpreted just not jumping the subroutine when the L#var parameter is 0, so when the parameter changes to other than 0 then it executes. Fixed.
- In demo mode the reset did not stop the jog if the jog key was held down while triggering the reset. This could not cause an issue for any machines, because it only effected the demo modes which can't control a machine.
- G64 and G68 codes display was not in the proper growing order, the larger number was displayed first, which was only a visual problem, fixed.
- Informplugin(s) function was added to the plugininterface. So far only the Informplugin(s) events were in the interface to let macros call plugins. Now plugins can call eachother.
- OSK plugin functionality was extended, plugin was updated. On-Screen Keyboard / Calculator (OSK) now automatically grows if display is high resolution. In the current profile under [UCCNC_OSK] section IgnoreFields key fields (usually for text input) can be excluded from OSK. The format is IgnoreFields=<fieldnumber>[,<fieldnumber>] without spaces. By default fields 1000 and 216 (MDI and Newprofilename) are already excluded. Also supports x64 platform.
- ESC keyboard key function was added to DRO editing to Delete and also exit from the DRO when pressed.
- Inches and millimeters CV option was added to the installer to install different default values for users using mm or inch units.
- M1 in subroutines did not work properly. Was broken when the G41/G42 was implemented. Fixed.
- G10 L1 R.. code did not work properly. Fixed.
- The internal variables (#vars) interpretation had a limitation (the same limitation which Mach3 also has) in it's working due to the motion buffering, that the #vars has to be advance calculated, so the external query of the vars did not give the proper timed value if there was a looking ahead in the g-code. The #vars value displayed was always what it was lastly calculated including the looking ahead. So, for example attaching a #var to an analog output and changing the value line by line could not work unless if there was a wait code after each value change which blocked the looking ahead. An example code to show this issue:
G0 X0
#1 = 1
G0 X1
#1 = 2
In this example the #1 value queried with the Getvar function or if it was attached to an analog output showed value 2 even while the G0 X1 code was being executed, because the software was looking ahead and already calculated the #1 to have value 2.
The working of this was now changed, the #vars are now pushed into the motion buffer and now the queries show the values in syncron with the g-code execution.
- App.config file was changed and installed with the installer to allow plugins compiled with .NET 2.0 and with different appdomain to run.
- The application was now compiled with AnyCPU and the associated steps were done to let the UCCNC run as an x64 process on 64-bit machines to let it take advantage of the 64bits architecture. Now the software runs as an x86 process on 32bits computers and it runs as x64 process on 64bits computers. The software can now load large g-code files on x64 computers. Was tested upto 500MBytes g-code file size, but ofcourse the file size limit depends on how many vectors does the g-code file contain.
The plugins which were compiled for x86 architecture will no more work on x64 Windows. The authors of the plugins have to change the target platform in their application to AnyCPU if they want their plugins to work on both platforms. The plugins which install with the UCCNC were all recompiled with AnyCPU and the example C# plugin template was also updated to AnyCPU, except the XHC and URC200 pendant plugins, these will be updated only in the next release, they will not work in this release version.
- The toolpath viewer drawing method was updated to use Vertex buffer object instead of Vertex buffer list to let it draw larger amounts of vertices associated with the larger file sizes which are supported by the x64 platform. For this reason the UCCNC now relies on the OpenGL 1.3 + the ARB_vertex_buffer_object OpenGL extension or the OpenGL 1.5. The software automatically selects between what to use, if one of them is available then the software will run. If the vertex buffer object is not supported at all by the graphics card then the software will show an error and will not run.
- M215 Px had an issue with updating the pulley in syncron with the g-code cycle execution, fixed.
- The 5441 motherboard firmware missed to have the internal pullup resistors configured on 2 of the inputs in the firmware, fixed.
- An issue with full circles execution was fixed, that if the software was forced to syncronise with the motion controller after a motion which movement gave the startpoint of the arc and then the full (360°) circle was executed after the code which caused the syncronisation and if the 1/steps per value was not an integer divisor of the endpoint then the circle was in some cases no more understood as a full circle by the motion software, because the syncronisation caused the start coordinates and the end coordinates to become different points, because the steps per value did not allow the programmed coordinate by resolution and so then the circle might not be executed depending on which side the start coordinate offset. The issue was fixed with the controller is now not syncronising the coordinates while in cycle except for certain operations which require the syncronisation.
- Rigid tapping and Thread cutting possibly missed to make the syncronous motion in some case (~1 out of few hundreds usually). This was fixed for the ethernet controllers only in the previous release and now the same was fixed for the USB controllers.