Quote from CS-Lab Support on 21 March 2023, 11:16

Manual handwheel and probing give the same error but have a different source.

In the case of probing, the problem is relatively easy to fix because it only requires us to adapt the plugin to the changes made by Art-Soft.

When it comes to a handwheel, things are not so simple.
By default (apart from our hardware-supported handwheel), Mach4, as the software, supports handwheels with algorithms to which we do not have access.
These algorithms generate a movement trajectory that must be followed by a CSMIO/IP controller.
If the CSMIO/IP controller reports the PID Fault while using a handwheel, it means that the trajectory is faulty.
We cannot say why it is defective because, as I wrote, we do not have access to Mach4 algorithms.

The issue may also lie in the macros and settings that support your handwheel.

Quote from TanTanCNC on 2 April 2023, 20:15

any news about the update for the CSMIO/IP software?

i cannot use probing now.

Quote from CS-Lab Support on 3 April 2023, 12:43

We are still waiting and apparently there are still some tests of the plugin.

Quote from TanTanCNC on 14 April 2023, 16:26

any updates????

see the reply on the Mach forum from mach developers.....

Hi,
there has been some discussion on this matter on the Mach4 General Discussion board. It would appear that build 5000 caused problems for more than just CSLabs.

Apparently certain sections of build 5000 code run very very much faster than had been the case with earlier build and various controllers including CSLabs have been caught out,
it causes a 'race' condition.

NFS has contacted all the manufacturers of Mach4 ready controllers and they are working towards a solution.

CSLabs responsiveness to this sort of issue used to be legendary, but in recent years their commitment to fixing plugin problems has diminished markedly. Shame really, CSLabs had an
enviable reputation.

Craig

Quote from CS-Lab Support on 21 April 2023, 14:10

Hi guys,

I will try to refer to the above statement and clarify the situation a bit.

• Our commitment to Mach3 support indeed used to be exemplary, but it wasn't just about quickly fixing bugs in the plugin and firmware. Our commitment, to a large extent, also consisted in fixing and improving the functionality of Mach3. We did this by blocking the unsatisfactory original Mach3 functionalities and recreating them in an improved form in the plugin and controller firmware. It was possible since Mach3 was almost at the end of its development, which gave us a free hand in modifications, and we did not have to worry that its next update would destroy our efforts.
• It is entirely different in the case of Mach4 because it's a constantly evolving project, and therefore we cannot act as freely as in the case of Mach3. The reason for this is simple, let's assume that our developers will improve the functioning of one of the Mach4 features on the plugin or firmware side, and in a few days Mach4 developers will do the same in Mach4. Such a situation could lead to a huge problem manifesting itself in dangerous or, at best incorrect operation of the machine.

 

• Mach4 is intended by the authors to implement as many functionalities as possible, thus limiting the role of the controller to the necessary minimum. It is a convenient solution for them because it gives a lot of freedom and possibilities while not causing the need to adjust the plugin and firmware on our part. Such action, however, negatively impacts the machine's functioning because some functions must be implemented on the controller's firmware side as its autonomous functions. A logical and well-thought-out division of tasks (functions) between Mach4 and the controller firmware improves the control system. A good example is the MPG function. Mach4 has its own MPG support, but it doesn't work great and requires writing a macro that handles the axis selection and pitch switches. Our controller also offers MPG support, the hardware support that works perfectly, and its configuration is straightforward and comes down to two mouse clicks.

 

• Our concept for a control system comes from the practice acquired during many machine retrofits and the fact that we are software and hardware developers. The concept of Mach4 developers seems a bit more theoretical and sometimes results in slightly overcomplicated solutions from the programming side. This causes a situation in which our developers have to spend a significant amount of time and effort, and sometimes they even have to use some kind of tricks to make Mach4 work correctly with our controllers.

 

• In many cases, our inquiries or bug reports remain unanswered, and the lack of the current SDK (the last SDK update for Mach4 was made five years ago) makes it hard, and we have to deal with it ourselves. An example here may be a case known to some from a few years ago, with a badly working THC feature in Mach4 (analog mode). This case took its toll on our mutual customers. We lost a lot of time trying to solve it. Eventually, to save their situation, we decided to quickly implement the THC feature to simCNC and make it available to dissatisfied customers so they don't have to wait any longer.

 

• As you know, we have had our own simCNC software for several years, which we are constantly developing and improving, making each version better and more reliable. In this situation, every moment is precious to us; therefore, we cannot afford to implement uncertain solutions for Mach4. Often we wait until the operation of the Mach4 feature is stabilized or adequately described in the SDK. This doesn't mean we deliberately underestimate the level of involvement for Mach4. Quite the opposite, an example of this is the common firmware for Mach4 and simCNC.

 

• Finally, I would like to refer to Mach4 5000 release briefly. According to our developers, this version reverts to the old solutions and maybe even has a few bugs. Unfortunately, we can't tell for sure without an up-to-date SDK and have to grope around a bit.

We want and will continue to support CSMIO/IP controllers with Mach4 and hope the situation will stabilize shortly and you all will be satisfied.

CS-Lab Team
support@cs-lab.eu

Quote from rob on 22 April 2023, 09:42

Thank you, excellent response to this issue 🙂

Quote from TanTanCNC on 18 July 2023, 16:17

downloaded the new 3.5000 driver.... that works a lot better. i did a few quick tests with the M4 5165 beta version, and it seems to work a lot better.

i tested probing, that seems to work

i tested a program that seems to work

i tested movement with the xhc pendant, that worked too, but had a fault when moven a lot of single steps in stepmode.

thank you for updating the driver!

Quote from CS-Lab Support on 19 July 2023, 13:32

Hello.

 

The plugin is only suitable for Mach4 4.2.0.5036.

 

>>> i tested movement with the xhc pendant, that worked too, but had a fault when moven a lot of single steps in stepmode.

 

                What is the fault?

                Do you have a photo?

Regards,

Wojtek

Quote from TanTanCNC on 20 July 2023, 14:58

hereby the images about the faults.

they occur when moving an axis in stepmode more than a few steps.