Hello Guest it is September 29, 2023, 07:32:14 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Fledermaus

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »
Mach4 General Discussion / Re: How to change probe parameters
« on: August 12, 2023, 05:53:24 PM »
The dro code for the OnModifyScript of each of the Probing settings needs to be changed in exactly the same way as you have already done for the PersistentDROs. See the example heare that I use for the FastFeed dro:

Code: [Select]
local inst = mc.mcGetInstance()
local val = select(1,...) -- Get the user supplied value.
mc.mcProfileWriteString(inst, "ProbingSettings", "FastFeed", string.format(val))
mc.mcCntlSetLastError(inst, "Probe: Fast find feedrate updated")
return val

Essentially, you should only need to modify line 2, replacing it by the select(1, …) statement, which retrieves the numeric value you typed into the field and saves it in the variable val; and to add the last line, if it  is missing, which returns your changes and allows the new value to be stored in the dro. The return statement must always be on the last line. That’s it!

Line3 saves a text representation of the new value in the machine.ini file. You can open this file in a text editor, e.g. Notepad, if you wish and search for the section [ProbingSettings] . Under this heading you will see all of the values that have been saved from the Settings screen. Previously, you were saving values in another section, [PersistentDROs]. All of these values are saved in the machine.ini file so that they can be retrieved and used to populate the on-screen dros next time you start Mach4.

Notice that val is a number and needs to be converted to a text string for use in the function mcProfileWriteString(). This conversion can be done with either the tostring() or string.format() functions, which are similar, so  either should work. In short, you shouldn’t need to change line 3. .

Line 4 simply writes a message to the status line at the bottom of the screen: its use is optional and you can alter the message element to suit your preferences should you wish. Again, it is not necessary to change this line.

I hope this helps you to see the similarity between what you are faced with now and what you previously tackled. As I said earlier, the sheer number of functions that need to be updated makes this a tedious procedure, but you may as well do all of them whilst it is fresh in your mind – it doesn’t actually take that long once you get into the swing of it. Best of luck!


Mach4 General Discussion / Re: How to change probe parameters
« on: August 11, 2023, 12:09:46 PM »
Something has gone wrong for you, as the new file refers to a different dro to the original one, and shows its original code using scr.GetProperty(), which, as you’ve discovered, no longer works.

Taking your example of droGageDiameter , you should modify and save the script so that it reads as follows:

Code: [Select]
local inst = mc.mcGetInstance()
local val = select(1,...)
mc.mcProfileWriteString(inst, "PersistentDROs", "droGageDiameter", string.format (val))
return val

This should then work, though you may find that you need to restart Mach4 after saving your changes. The secret lies mainly in the select statement on line 2, which retrieves the value you type in rather than the pre-existing value of the dro.


Mach4 General Discussion / Re: How to change probe parameters
« on: August 11, 2023, 05:30:12 AM »
It sounds like you may be using old code that no longer works. I first experienced this issue with 5036 .

You need to open the screen editor, highlight the dro, select Events and open the On Modify script to see if it resembles the following :

Code: [Select]
local inst = mc.mcGetInstance()
local val = select(1,...) -- Get the user supplied value.
mc.mcProfileWriteString(inst, "PersistentDROs", "droName", string.format (val)) --Create a register and write to it
return val

If not , modify your  script to match the above template, being sure to use the actual dro name in line 3.

Assuming this works for you, repeat the process for each dro in turn. It’s a bit tedious, but at least in my case, effective. 

Hope this helps.


CS-Lab / Re: New CS Lab plugin 3.122 released
« on: July 01, 2019, 09:31:39 AM »
I did have to re-program the analogue output, which had for some reason been disabled in the CSMIO plugin. Having done that, however, everything worked fine.  I have been drilling this morning, and the S command is working perfectly both from the MDI and from a Gcode program.

Note that I have the IP/A, and maybe it behaves differently from your IP/S.


CS-Lab / New CS Lab plugin 3.122 released
« on: June 30, 2019, 05:14:25 PM »
CS Lab introduced its latest plugin 3.122 a little over a week ago. The focus of this update was to correct  problems that some users, myself included, were experiencing with the MPG. The update itself takes place in two steps. First, the CS Lab Maintenance utility is run in the usual way, and updates the Mach4 plugin and the controller firmware. Power should then be removed from the entire system. When it is next switched on, the MPG module firmware will be automatically updated. A message to this effect is shown on the Mach4 screen.

As far as I can judge to date, the MPG operates correctly following this fix. For those unfamiliar with it, the CS Lab MPG module works similarly to those found on industrial mills. Operation is controlled by the real time firmware within the units. This makes the encoder noticeably more responsive than one operating via Mach4. Providing your acceleration and velocity limits are not exveeded, motion will follow the encoder movement whilst it is turned, and stop when turning ceases. This is very reassuring compared with systems that run on after turning stops. Should the encoder be turned too quickly, steps will be lost, but the resulting motion will always be a whole number of steps.

Understand that when the MPG is in use, CS Lab implements its own motion planner, and Mach4 motion is temporarily inhibited. After use, the pendant should be switched to its OFF position so that normal Mach4 operation can resume.

Thanks are due to Andrzej Rogozynski at CS Lab for his work in identifying and fixing the problems.


CS-Lab / New CS Lab plugin 3.121 released
« on: June 02, 2019, 04:16:40 PM »
I have been using the latest CS Lab plugin 3.121 with and IP/A for the last week or so. On the whole, the upgrade from 3.016 has proved a positive experience, and overcomes probing issues I experienced with 3.120, these causing me to revert to 3.016. Gcode programs, including macros, continue to run faultlessly.

The new feature you will first notice , introduced in 3.120, is the ability to define a default controller, obviating the need to select your hardware each time Mach4 is started. This was a welcome addition.

Also new is support for backlash compensation. I have tested this for the 3 axes on my mill, and it appears to be effective and reliable.

Probing works well , at least for Probe0 and Probe1 which I have used extensively. I have not tested Probe2 or Probe3 though these worked in the past so I would not anticipate issues here.

Probe protection, recently introduced in the plugin,  works well for Probe0, halting motion for an unintended strike whilst the table is in motion, but ignoring strikes when the table is stationary. This is exactly what I would expect.. Note, however, that this protection is only afforded to Probe0.

I have never had a good experience with the MPG support within the plugin. With this latest release, when it works, it works very well, being immediately responsive to a touch of the encoder wheel, and stopping motion as soon as the wheel is stationary. I prefer this type of action to that which allows an overrun when the wheel is released:it is much safer.  There is a dead spot at THE WHEEL'S INITIAL POSITION:  in effect there are 2 ADJACENT ENCODER positions WHERE ITS REGISTER INDICATES ZERO. On the negative side, the jog weel can unexpectedly become unresponsive until the MPG axis is re-selected. It also becomes unresponsive following use of the on screen jog buttons, this time requiring a press of Mach4's Reset button to re-activate it. Most seriously of all, the MPG can get into a state where positive rotation results in double movement increments, and negative rotation causes a judder with no net movenemt. Clearly this can be destructive: you would not welcome twice the expected movement if you are approaching a hard surface with the tool. Oddly, register values behave normally in this condition.  Note that I am using a cheap wired Chinese pendant connected to the CSMIO-MPG module.

I experience occasional PID errors when Mach4 enters the enabled state. These seem to be fairly random. This has never occurred during normal program operation however, and a PID error does not cause position to be lost with the IP/A.  This issue appears to have arisen since version 3.016.

Machine position is still reset to 0 following configuration, even if no changes are made.

Documentation and release notes have not yet been updated.


CS-Lab / Re: New CSMIO plugin v3.120 released May 2019
« on: May 25, 2019, 05:19:19 PM »
I did a bit of work using the newest v3.121 plugin recently. This release has fixed the issue with probe 1 (and by inference probes 2 and 3) that was evident in v3.120.

I nearly got caught out as the upgrade from v3.016 to v3.121 left the analogue output  to my VFD disabled, and I only just got to the Estop as the cutter levelled with the workpiece. As it was rotating at 500 instead of 5000 rpm to cut a full width groove disaster would quickly have followed. OK, I should have tested more carefully before launching into a job, but after the scare I have added some protection code to the M3 and M4 macros to halt motion if such a condition arises in future.

Otherwise I haven't had any issues using this latest release.


CS-Lab / Re: New CSMIO plugin v3.120 released May 2019
« on: May 20, 2019, 04:52:32 PM »
A new plugin, v3.121, has been released.  I haven't installed it, though will probably give it a whirl later in the week . Yet again there are no release notes for it.


CS-Lab / Re: New CSMIO plugin v3.120 released May 2019
« on: May 09, 2019, 07:00:39 AM »
Glad it worked out for you. Odd that I never had that issue with the IP/A.
I too would like to see the release notes updated in a timely manner so we have some idea what needs testing.


CS-Lab / Re: New CSMIO plugin v3.120 released May 2019
« on: May 08, 2019, 05:05:03 PM »
If you already have a controller and firmware installation, you can use the CSMIO maintenance utility found in your program files  (x86) folder:


If not, all CS Lab software  for CSMIO products can be found here:



Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »