Hello Guest it is April 29, 2024, 12:12:32 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 »
11
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.

Allan

12
Craig's approach  is absolutely right.

Allan

13
As far as I know, there is only a single set of variables. These are updated by the most recent probe strike, whether it is probe 1, 2, 3 or 4. At least that is how it works for me using a CS Lab controller..

Allan

14
Mach4 General Discussion / Re: Mach4 bore probing.
« on: March 24, 2019, 06:28:32 PM »
Craig

As you know, I use the IP/A, and from what we read above, this may behave differently to the IP/S and IP/M, despite using notionally the same plugin release.

To be honest, I have had no issues since the release of version 3.16 of the plugin. Having said this, I do not work at the cutting edge. I have a 3 axis mill with servos, a VFD for spindle control, a touch probe, and a tool height sensor. That's it - it couldn't be much simpler. As faras I can tell, the CSMIO-IP/A behaves faultlessly in running this system. I use combined limit/home switches together with index homing which works admirably.  Pertaining to the topic, I use a modified version of the probing module, and have extensively used all but the angular functions over numerous builds of Mach4 (my current build is 4109). Earlier plugings were problematic, but probing seems to have been nailed in 3.16.

In terms of extenders, I don't have the need for I/O or the encoder module and have no idea whether these work fully with Mach4. I do use the CSMIO-MPG in conjunction with a cheap Chinese wired Jog pendant. The plugin should support the pendant without any need for programming, but I have never got this to work properly. Details have varied between plugin releases, but with 3.16 the machine jogs perfectly in one direction, but in the other it moves and and immediately returns to its starting point. I will test this again when we get an update. The pendant is visible as Mach4 registers, however and the values here properly reflect the control actions. So it was a simple matter for me to take the register values for axis and increment and program a couple of functions which I call at 5/second using the PLC. The encoder wheel is handled via MPG #0 in Mach's configuration. This all works 100% reliably, though I am aware of a fraction of a second delay between turning the encoder wheel and the table moving, making it a little less responsive than the plugin's native support but nevertheless eminently usable.

I would like to see Backlash compensation added, despite its limitations (I have added BC to the probing module for more accurate centre and bore measurements). I cannot say whether Spindle orientation or Rigid tapping are available, as they could function via the CSMIO-ENC module. I don't have the luxury of an ATC and have decided that it is easier and cheaper to use thread mills than to fit a spindle encoder.

The hardware is mechanically and electrically robust and noise levels are extremely low. All signal connectors are gold plated. The 2 internal circuit boards appear well designed and free from last minute modifications.

My main frustration is lack of active support. It is 9 months since version 3.16 of the plugin was released, and there is no indication of when (or if) there will be an update and what features or fixes it may contain.

In addition, the main manuals stem from the days of version 2x of the plugin, using Mach3. Though there is the  minimum of essential information relating to plugin 3.x and Mach4 in a couple of additional documents, these are quite brief and I feel it it time the core manuals were re-written in an up to date form. I presume that CS Labs, being a small company, have probably had their hands full with the development of their SimCNC software. I have no interest in this. It may be more appropriate to high speed systems with its S curve planner, but I like the adaptability of Mach4 and will continue to use it.

Will CS Labs eventually drop support for Mach4? That's anyone's guess, but I hope not. Perhaps they were anxious about Mach4 take up. One positive indicator is that the plugin is common to both Mach4 and SimCNC.

Allan

15
Mach4 General Discussion / Re: Mach4 bore probing.
« on: March 16, 2019, 08:01:53 AM »
Interesting, but I'm not holding my breath for it.

I am currently using build 4109 of Mach4 with the IP/A and plugin 3.16 and have used probing extensively without any problems. I wonder if the issue affects only the step/direction versions of the controller? Otherwise, could it be specific to Win10 (I use Win7 32 bit)?

Allan

16
Had same problem with releases newer than 4054 on Win7 32 bit.

This was resolved using the above compatability fix thanks.

Allan

17
CS-Lab / Re: Index Homing
« on: December 23, 2018, 05:45:08 AM »
Glad you seem to have got it working again.

Strange occurrence though. Did you re-flash with the same plugin version or was this updated?

Allan

18
Mach4 General Discussion / Re: Mach4 bore probing.
« on: December 22, 2018, 11:51:07 AM »
Had a bit of spare time today so fired up the mill and re-configured it to use the standard Mach4Mill WX4 screen set and standard probing module. Mach4 v3882, CSMIO-IP/A with plugin 3.16, probing module dated July 2017.

I set probe 0 to use G31.0, fast feed 500mm/min, slow feed 10mm/min, overshoot 2mm, backoff 0.25mm.

I used the Bore function to probe a 24mm i.d.  rin and also performed both offset and radius calibrations using the same ring. All worked perfectly, so what you are  getting wrong I don't know.

Allan

19
CS-Lab / Re: Index Homing
« on: December 22, 2018, 06:03:46 AM »
From your description it sounds as if you have wired and set everything correctly. I assume that you have powered your encoder with 0V and +5V from the CSMIO.

Can you verify with your DMM that the CSMIO is actually getting the differential index pulse (both +ve and -ve) from the new encoder?  Assuming you are using plugin 2.910, as you said the system was several years old, I think the CSMIO diagnostic contains a page that indicates how many counts from the limit switch opening occur before the index pulse is received. These values should be nominally half a motor turn (approximately 4096 pulses).

If CSMIO is getting the index signal but is not responding to it, I think it is time to check the CSMIO itself. To do this you would need to connect the encoder to a spare channel on the CSMIO and then program this channel as the encoder input in the plugin config.

Allan

20
CS-Lab / Re: Index Homing
« on: December 21, 2018, 04:55:48 PM »
This is making no sense to me: how can your servo operate correctly if the steps per unit has no effect? Is the same encoder used by both your servo amplifier and your CSMIO, or do you have separate encoders for each? Is the CSMIO encoder input fed directly from the encoder or via an encoder output of your servo drive?

I think you need to go back to the CSMIO plugin and check that your Y axis is configured to use the proper encoder channel.

Allan

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