Hello Guest it is September 21, 2023, 09:11:51 AM

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.

Topics - Fledermaus

Pages: 1
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 / New CSMIO plugin v3.120 released May 2019
« on: May 06, 2019, 05:43:49 PM »
I have been using the CS Lab IP/A with plugin 3.016 since its introduction a year ago. within its limitations it has performed without any real issues on my 3 axis mill. I currently have Mach4 build 4162 and Windows 7 32 bit.
I tried the latest plugin 3.120 over the weekend, and have the following observations, which may be helpful to others thinking about upgrading to this new plugin, released on May 1st.

•   I welcome the inclusion of a default MAC address. Like many users, I currently have only one controller and it was irritating having to select that controller each time Mach4 was started.  A further improvement would be to keep looking
 for a connection if none is found, e.g. because Mach4 has been started too soon after powering up the system.

•   I tested the (I think new) probe protection feature. Using probe00, this appears to work well, instantly stopping motion if the probe is struck whilst the table is in motion, yet ignoring the strike if the table is stationary: exactly as I would expect.
Protection did not work for probe1, which I use for tool height sensing, and by inference for probes 2 and 3. This seems to be an omission.   (It is not difficult to implement this in LUA if you need it.)

•   I ran some quick bore probing checks using probe0 and this continues to work well. However my tool height routine using probe1 now causes Mach4 to disconnect from the controller just prior to any G31.1 motion. When Mach4 is re-started, anAssert window is displayed, presumably by debug code. I don’t understand exactly what this message means, though it seems to involve magic number 1 and implicates the use of probe1 in some way. Tool height sensing has been working 100% for the past year with plugin 3.016 so I am inclined to think the error is caused by a change in the new plugin.  By implication, I would expect G31.2 and G31.3 to fail in a similar way.

•   I tried the plugin’s built in MPG support with my Chinese 4 axis wired pendant. This did not work for me in plugin 3.016 and 3.120 is just the same: If I turn the encoder slowly in one direction it steps 2 units at a time, and in the other direction it steps forward and then immediately reverses giving a net movement of zero. I would like to make use of this as it is very responsive, but clearly cannot do so with its current behaviour. I will continue using Mach4’s MPG feature, which, though slightly less responsive, works well. As this relies on the plugin’s register values, I fail to understand why these result in good motion whereas the built-in function does not.

•   Machine position is still reset to 0 following configuration, even if no changes are made.  This seems an unnecessary inconvenience as the IP/A should not need to be re-homed

•   Certain functions that were available with plugin 2.910 are still not implemented in v3.120 e.g. Backlash compensation, THC, and servo spindle with Align at stop(maybe this can be done with index homing on an out of band axis flagged with mcAxisSetSpindle)..

•   Documentation and Change notes are not being kept up to date

I have to say that after a gap of a year, I find the new plugin disappointing, both in the loss of probe functionality, and in its lack of significant new features. Hopefully now that SimCNC is nearing release CS Lab will be able to devote some more time to documenting and enhancing the plugin to restore their somewhat damaged reputation among Mach4 users..  But don't hold your breath.

I have emailed CS Lab regarding the above issues.


Mach4 General Discussion / Mach4 build 3372 hangs with CSMIO/IP-A
« on: April 28, 2017, 05:24:22 PM »

I use a CS Lab CSMIO/IP-A controller and have generally had good results with Mach4 using plugin version 2.910.

Disturbingly, recent versions of Mach4, including builds 3346 and 3372, appear to be incompatible with the CSMIO/IP-A, preventing motor operation. When Mach4 is started, the controller's internal temperature and voltages are correctly reported, suggesting basic communication is OK. However the CSMIO log file indicates that all calls to mcMotorGetInfoStruct() have failed. Opening Mach4's log file shows it to be flooded with repeated mcMotorIsStill() calls and causes Mach4 to hang. Clearly all is not well.

Version 3233 mostly works well but probing intermittenrly hangs. No probe movement occurs and the PLC is frozen. Mach4 is essentially dead, although the screen remains superficially responsive. The Mach4 log file indicates normal behaviour for G31 up to the point where motor stop reports are requested followed by "Waiting on SetStill..." No further log entries are made. Perhaps this is related to the motor issue with 3372.

Has anyone else seen such behaviour and/or can you suggest the possible cause or resolution? I tend to assume Mach4 is the culprit as nothing else has changed.


Mach4 General Discussion / Error in probing module?
« on: April 10, 2017, 09:17:12 AM »
I think there is an error in the interpretation of probe offsets within the probing module mcProbing.lua. The offsets XOffset and YOffset are defined during calibration as:

   Offset = Measured value - True value

(XPos and YPos are the variables representing  the true values as input by the user to the calibration function  Probing.XYOffsetCal.)  It therefore follows that these offsets should be subtracted from future probe measurements in order to achieve the desired correction to probe readings. In fact they are added, thereby increasing rather than minimising probing errors.

The solution is simply to replace all occurrences of the string "+ XOffset" by "- XOffset" and similarly for YOffset. In all there are 86 such occurrences, so you will want to use the Find and Replace tool in your editor to facilitate this.


I've been mystified for some time as to why Mach4 occasionally fails to pause and call my M6 macro when a tool is selected within a gcode program. At other times Mach behaves as expected, even using the same gcode file.

I eventually tracked this down to the toolpath display. My (customized) screen set ordinarily hides the toolpath displays on background tabs. When no toolpath is visible, the pause for toolchange and the M6 macro call are skipped. If any of the toolpaths are displayed, even briefly, prior to gcode execution, all works as expected: the program pauses and M6 is called. This is the case both for the simulator and my CSMIO/IP-A controller.

My personal feeling is that this behaviour is a bug: the user should be free to rearrange a screen set without disrupting core operations. Has anyone else seen this behaviour and found a solution other than always having a toolpath on display?

I haven't noticed any effect other than skipping of the tool change action: the gcode otherwise seens to run normally.


Pages: 1