- Improved loading speed in the graphical user interface
- Calling Subroutines from a Main Program
- Better usability when working with custom G-code-wrapper files
- New surface language Estonian
- Tool data available in English
- Date picker when creating a diagnosis file
- neo rotary axis also on M8Cube, MLCube and M10Pro
Improved loading speed in the graphical user interface
The loading speed of the graphical user interface of DATRON next has been improved with Release 2.6. For example, if you jump from the home screen to the program or tool management, the screen content is displayed much faster and you can operate it more quickly. The improvement is particularly noticeable with DATRON neo.
Note: Note that the effect only occurs after the second call of the respective submenu. Only then the data is loaded from a buffer that is generated the first time it is called.
Calling Subroutines from a Main Program
As of now it is possible to call subroutines (with file extension.simpl) from a main program. This function is useful, for example, if several programs are to be processed one after the other. Up to now this was only possible with external SimPL sequences (file extension.seq).
During processing, the main program of the external module is executed, including all subroutines and embedded sequences called by it. To do this, the subroutine must first be specified in the header of the module to be called via a user module declaration.
Better usability when working with custom G-code-wrapper files
G-code commands according to ISO standards are already implemented as standard in DATRON next. If you want to use G-code commands outside the ISO standard or your own G-code commands, a so-called G-code wrapper file is available. In it you can even assign certain SimPL commands to G-code commands. With version 2.6 minor improvements in operation have been made. In the Samples folder in the program management you will find the supplied G-code wrapper file. To adapt these to your needs, proceed as follows:
- make a copy of the G-code wrapper file and place it in another folder, e.g. the Machine folder.
- modify the file content according to your wishes.
- save the file.
- link the file to use it. The following functions are available for this:
- Link: The modified G-code wrapper file is used to execute all SimPL programs.
- Unlink: The modified G-code wrapper file is not used.
- Show shortcut: The currently linked G-code wrapper is displayed.
Attention: If the G-code wrapper has been changed in the Samples folder, a new G-code wrapper with factory settings can be created. To do this, press the reset button (see graphic above). The entire Samples folder will be reset to the factory default. Your created and modified files will be deleted in the Samples folder! So make backups of your files beforehand. In any case, make a copy of your modified G-code wrapper file in another folder (e.g. Machine).
New surface language Estonian
With version 2.6, the user interface of DATRON next is also available in Estonian.
Tool data available in English
In the DATRON next tool catalog, the title and description are now also displayed in English language. Previously, these were only available in German. English is now also the standard language – if the surface language is set to Spanish, for example, the tool data is displayed in English.
Date picker when creating a diagnosis file
In combination with the DARTRON service it may be necessary to create a diagnostic file. A convenient date picker can be used to limit the time over which the file is to be created.
neo rotary axis also on M8Cube, MLCube and M10Pro
Starting with version 2.6 of DATRON next, it is also possible to use the neo rotary axis on M8Cube, MLCube and M10Pro machines. The axis is always displayed as an A-axis regardless of the orientation on the table.
Note: Please note that a service intervention is required for retrofitting on your machine.
For a better understanding of this function, the following is an excerpt from the SimPL command reference (7.3.5 Calling the main method of another SimPL module as a subroutine):
usermodule name = “location”
name must be a valid and unique SimPL identifier, i.e. there must be no program, no global variable and no sequence with the same name in the module. Location determines where the other module is searched for and has the general form “location:path”. The interpretation of the path depends on the value specified for location:
| Location | Path |
|---|---|
| machine | Path identifies a module which is located in the internal program memory of the machine (in the program management below the root folder'Machine') |
| device | Path identifies a module located on an external memory connected via USB (each USB device is represented in the program management by its own root folder) |
| network | Path identifies a module which is below an external network folder included via the user settings (each network folder is represented by its own root folder in the program management) |
| relative | This path identifies a module that is in the same location as the calling module. The value 'relative' is the default value, i.e.: If no location is specified,'relative' is implicitly effective. |
For paths, specify relative paths whose components must be separated by separators (/ or \). If an absolute path is specified – i.e. the path starts with a separator, this is ignored. Within paths, upper and lower case is ignored. Spaces within paths are NOT ignored, so folders or file names that contain spaces are also supported. The last part of a path is always the name of the program file, e.g. subroutine_1.simpl. If the location is device or network, the first part of a path must always be the name of the device or network folder (as displayed in the program management). If an external device has no name, the first part of the path must be a single ?.
Examples of valid user module declarations:
usermodule UP_1 = “machine:\unterprogramme\bohren\lochkreis.simpl”
The subroutine with the names lochkreis.simpl is located below the internal folder Machine/unterprogramme/bohren.
usermodule UP_2=”device:PROGRAMME\test.simpl”
The subroutine named test.simpl is located on the external USB device with the name PROGRAMME directly in the root folder.
usermodule UP_3 = “device:?/zum testen/test.simpl”
The subroutine named test.simpl is located on an external USB device without a name in the folder ‚zum testen‘.
usermodule UP_4 = “network:Aufträge\2018\CAM_FUSION\Auftrag 42.simpl”
The subroutine named’Job 42.simpl’ is located in an external network folder called Jobs in the subfolder 2018/CAM_FUSION
usermodule UP_5 = “relative:teil_1.simpl”
The subroutine with the names teil_1.simpl is in the same folder as the calling program
usermodule UP_6 = “Unterprogramme/teil_1.simpl”
The subroutine with the name teil_1.simpl is located in the same’location’ as the calling program, in a subfolder called subroutines.
If an external module is referenced by a user module declaration, the identifier from this declaration can be used as a statement within the entire module (as often as required). When this statement is processed, the main program of the external module is executed as a subroutine, including all the subroutines and embedded sequences it calls.
This mechanism can also be used ‘nested’. This means: If an external module whose main method is called by ‘usermodule’ declaration references other modules by usermodule, these are also called. Please note that relative paths in usermodule declarations are always relative to the location of the direct caller.
Currently there are the following restrictions for user module calls:
- A name declared by usermodule can NOT be called from embedded or external sequences (error message : Invalid statement)
- A main program which calls external sequences cannot be integrated via user modules (error message: sequence file not found).
