Messages

51

General Mach Discussion / Re: re : Mach turn ,tool radius index too big

« on: January 09, 2012, 01:39:19 PM »

Hi Guys,
Dusty contacted me about this topic on the CVI support forum forum - I thought I'd offer an update.

I suspect the root problem was with Mach 3.43.22 and PP driver 570 (which is what Dusty tells me he had running when he experienced this issue).
For MSM use, we recommend mach 3.43.37 (which also installs PP driver 601). I've settled on mach 3.43.37 as the MSM recommendation as it has patches for some serious safety issues that exist with the lockdown (3.43.22) rev.
(BTW, if you want mach 3.43.37, it is avail (via permission) from the CVI web site download area at www.CalyopsoVentures.com since it is not on the FTP page of Machsupport.com)

It looks as if the index pulse problem exists with the PP 570 level driver but is fixed in the 601 level driver.
I have some hints as to what the internal issue is in the 570 PP driver from correspondence with Art, and it involves changes in how plug-ins and the PP driver interact wrt to updating the RPM DRO (39) - I suspect the change Art made for that also fixed whatever this issue is in the 570 PP driver re threading sync (as there is only one input pin for the index pulse, the driver does both the RPM DRO update and Threading sync handling).

In any case, whatever the mach bug is, it seems not to exist with mach 3.43.37 and PP driver 601. I did not go back and verify the bug on 3.43.22 and driver 570 (as that would have required time that I didn't want to spend just to verify a mach bug).

FYI - to test this I set up a test system, connected to a PMDX125 breakout board on my test bench. It is fully configured for 3 axes and I'm using a signal generator to supply index pulses to the BoB - so I know it's getting nice square 50% duty cycle index pulses and I can vary the pulse speed to anything needed. Essentially this is a complete PP control system that just is not hooked to motor drivers (though the motor tunings etc are all configured).

I then set up 3 mach profiles, the only difference between the three are the profile names and the screen set the profile loads.
The first profile loads the mach 1024.set screen and gives stock mach mill mode.
The second profile loads the mach 1024.lset screen and gives stock mach lathe mode.
The third profile loads MSM.

I've used the test set up to run mach with 1024 mill, mach with 1024 lathe and mach with MSM, shifting from one to the other in all possible combinations.  I can do that and I can run the threading test gcode (that Dusty said failed for him) every time without problem. I've also not had any trouble running any other gocde with any of the profiles - so the "proof by example that it's possible" is not dependent on the single gcode test case. I think that verifies that it is indeed possible to run MSM and mach lathe on the same PC without needing to uninstall MSM and reinstall Mach to make a lathe work.

So to set the record straight for those that may find this thread in the future, while using MSM may have illuminated the situation, the root issue is not an MSM bug, it is a mach bug.  

Finally, from a post he made on the MSM forum, I have the impression that Dusty has this solved too - I've pinged him to verify that and am currently awaiting an ack that the mach update resolved this for him too.

Dave

52

Newfangled Solutions Mach3 Wizards / Re: NEW!! Drill Wizard

« on: December 27, 2011, 03:53:08 PM »

Hi,
Ron contacted me about this and I've looked into it a bit after being out of town for Xmas.

It appears to me tha Ron has found a general limitation with the mach #expand feature (a script programming feature).
Glossing over the tech details, it appears that when mach loads a wizard, mach treats the wizard as if it were a separate screen set. Unfortunately, that causes mach's #expand handling to not work well in this scenario. 

While MSM is probably the most popular screen set that uses #expand, I believe that this problem would occur with any MCode that uses #expand in the script for the MCode implementation. If an Mcode script it is invoked from a wizard directly and the script uses #expand, the problem happens. Wizards that post Gcode back to mach to get run from the non-wizard environment will be ok. 

It seems that the interactive nature of the new drill wizard is treading new ground for mach.

I'm thinking that maybe Ron and I can work out a proposal for what mach should do in these cases and then maybe we can get Brian to implement some improvements to mach's #expand handling.
So while we'll continue the conversation, this one may take some time as it will probably require some mach changes (which neither Ron nor I have control of).

Dave

yes indeed, I'm using MSM and yes indeed I doesn't try drillwiz with other screen set.
I hope you and Dave can find a fix for this.

many thanks,
Seb

53

General Mach Discussion / Re: G31 Probe problem

« on: December 13, 2011, 11:35:47 AM »

Ian -
interesting.... When I ran into the M6 vs IsaMoving problem, Brain told me that IsMoving only works for movement.
The counting test case shows that information to be wrong.

So that leaves us with the question of "When does IsMoving work as a sync function and when does it not?".
Alas, I don't have an answer for that question.

Terry -
Well, I've found in multiple cases that what Art said mach will do has gotten changed since the torch passed on.
The M6 vs IsMoving case is a counter example to what you report Art has said - thus we know it doesn't "always" work.
Which takes me back to the question above - for which there does not seem to be a known answer....  

If I had to guess, and it's only a guess, I'd suspect that the problems stem from the parallelization of mach - coupled with mach calling itself recursively (which assumes Mach was written to be rentrant), which I suspect is not part of the source code design.  This would match the observations that Ismoving works much of the time, but does not work, at least for situations where mach effectively calls itself (to call user scripts) - like the M6 example.

Dave

54

General Mach Discussion / Re: G31 Probe problem

« on: December 06, 2011, 09:47:05 PM »

Mark,
I'm pretty sure this is a Mach bug. I just reproduced the same symptom on a PP system.

Test sequence to demo bug:
(Feed and distance #’s are in imperial units).
1) Start machine
2) ref all home
3) zero X, Y & Z   (WC now = MC)
4) MDI: G90 G54 x.5 y-.5 z-.5    (we will call this location P1)
5) taped probe shaft over so is permanently triggered
6) MDI: F40
7) MDI: G91 G31 X1
8 ) Mach shows error about probe already being triggered on the status line. This is correct, but mach seem to then fail to abort the G31 and instead this motion sequence starts:
9) At a feed rate of about f=0.4 (as shown on run screen for actual F rate) all three axes start toward 0,0,0
10) at around 0.2, -0.2, -0.2 the F drops to about 0.0001"/sec (this is where all the time goes.....)
11) Several minutes later, it seems to give up on this slow feed rate and then at the normal home reference motion rate it does the ref all action (X then Y then X) and goes to the home position.
12) then at the 0.4 F rate it starts moving back toward P1
13) when P1 is reached, it loops back to step 9) and this seems to go on forever.

14) hit esc key to kill motion.

Verified on Mach 3.43.37

Dave

55

General Mach Discussion / Re: G31 Probe problem

« on: December 06, 2011, 06:31:58 PM »

Hi Ray -
Oh NO you don't - I won't let you blame me for that one! 
(well I guess you could, but I was not the instigator and am not responsible).

The history as I know it:

In days of yore (the era of Art), mach was essentially single threaded code internally. In those days all calls to the "code" API were synchronous - there was no other choice - that was how the APIs worked (whether by design or by accident).

One of the things Brian did (so he has told me) was to change a bunch of mach internals to be mutli threaded... 
AFAIK that was where the problems with the Code call began. Suddenly the Code started returning before the code string was executed - the multi-threading changes changed the semantics for existing scripts. Instant lack of backward compatibility was the result.

What I think should have happened was that Brian should have implemented the existing code call to be sync and added a new "QueueCodeAndReturnBeforeDone" call. That would have preserved the semantics of existing scripts. For whatever reasons,  Brian choose not to take that approach.

To complicate things further, after the multi threading change, there were some attempts to restore the old semantics. Some mach versions that had sync code calls and some did not - and it swapped back and forth a few times. Add to that the fact that back then there was no call to get the mach version... so you could not even check for what the semantics were on the version you found yourself running on...

All I did back then as ask for the addition of a call to get the mach version. I figured if I could get the version, at least I could code for version dependencies. (Alas, that bit of idealism on my part depends on having a good record of what changes are in each version - something that, in IMHO, is not Brian's strong suit).

After the uproar the multi threading changes caused quieted down, people started using "IsMoving" as the only sync tool available. "When the only tool you own is a hammer, all problems look like nails...." 

That led to another set of changes... when people put the IsMoving in a hard loop the CPU got starved out - so we had to add sleep statements. Then Brain forced a sleep equiv internal to IsMoving... but again you could not tell when you need to use and when you do not - so people put it in and on many mach versions I suspect the scripts end up wasting time in "extra" sleeps.

Now, then, I regurgitate all this in order to set the stage for this statement:

IsMoving really is a IsMoving wait.
It is NOT a general sync method to cause a pause until mach finishes the action you requested via a CB API.

Since the advent of the multi threading change, there is NO GENERAL WAY TO CALL MACH AND RELIABLY WAIT until the API call is complete.

I too used accept the Mach urban lore that IsMoving was was a misnamed sync call, and that it was an API sync mechanism.
It seems to do no harm if used for an API that does not cause movement, as in that case there is no movement in process and so the IsMoving call just returns false and your wait loop exits quickly. 

Here is how I learned that it really, truely, is only a wait for movement to stop.
I got into trouble when I tried to do this sequence:

Code("m6")
While IsMoving()
    Sleep 100
wend

If ISMoving really were a sync mechanism for the Code call, the script would hang in the IsMoving loop until the M6 competes.
That is NOT what happens.

M6 is particularly nasty example - from the gcode language standpoint, a single command was called for and you do not want to go on until the M6 is over, finished and done with.

Looping on IsMoving will not accomplish that desire! You will only pause until the "current motion" is complete.
Think about how mach implements M6 as a series of calls to user scripts and the problems become more apparent. In the case of M6, there is NOT a 1:1 mapping between gcode word execution and movement. The IsMoving loop technique effectively only works when there is a 1:1 mapping between gcode word execution and movement.

Alas, not even then does it always work... The problem is that an IsMoving loop depends on a motion having been started before the code call returns to the calling script - and due to multi threaded driven timing holes inside mach that may not always happen. Most of the time it does, but not all the time.

IHMO the sad fact is that this is an area where mach is fundamentally broken and there are no tools available to the script programmer to handle this reliably. Mach's script APIs (and Mach itself) has no concept of critical resources, locks, semaphores etc.

Frankly, I think it's pure dumb luck that mach scripts work as well as they do considering the multi-threading stuff and total lack of resource locking.

Dave

Just and update to what I said about FIFO and one-shot. I'm not sure but I think this has changed at some time. I THINK you can now send multiple CODE statements without an isMoving() after each one. I THINK you can now get away with a series of CODE statements with just one while isMoving() after the last one. i.e. I THINK Mach buffers the CODE requests in order. Is it reliable? - your guess is as good as mine - which version do I think it changed in? - I don't know. I still stick an isMoving() after each one - but that's just me.

Ian

Ian,

That is correct.  That change was made perhaps two years ago, back around v30-something.  It was done at the request of David Bagby, to make MachStdScreen work better.  AFAIK, it does work reliably.

Regards,
Ray L.

56

General Mach Discussion / Re: Tool hight measuring after tool change - macro ?

« on: November 03, 2011, 06:55:09 PM »

Hi,
You can also look at the extensive tool measurement and TLO setting support built into MachStdMill - visit
www.CalypsoVentures.com for more info.

Dave

57

Newfangled Solutions Mach3 Wizards / Re: NEW!! Drill Wizard

« on: October 05, 2011, 08:21:29 PM »

Rich,
Looks that way...

There is a call "GetMachVersion" that returns the mach version - the wizards could call it when started and then and tell you that the mach version is too old for the wizard - but that does not work for all cases - the problem is that the GetMachVersion call was added in 3.42.30 - so it's of use since then... but if you try to call it on a version < 3.42.30, mach gives the script a fault before the script gets the version info - so you get stuck in a catch 22 situation.

Dave

58

Newfangled Solutions Mach3 Wizards / Re: NEW!! Drill Wizard

« on: October 05, 2011, 07:04:12 PM »

Hi Ron,
The #Expand and other stuff was all introduced in the mach 3.43.xx series (they're not in the 3.42.xx series).
So the current lock down (3.43.22) would be the oldest and also currently available version with those interfaces.

Dave

59

CVI MachStdMill (MSM) / Re: touch off plate

« on: September 20, 2011, 04:36:55 PM »

Hi -
That's no problem - You need the MSM Professional Edition (as it's really a probing operation that is being done when the mobile touch plate is used and the probing stuff is not in the personal edition).

For details and options, please see the user manual, but here's the overview:

1) Since you are wanting to use a touch plate in place of a gage block, we need to tell MSM we're doing that.
On the settings common page, turn on the "G-Blk is TP" button to tell MSM that you are using a TP as a gage block.
The parameters for the mobile TP use are covered in the user manual section 10.3.1.7.3

2) the probe back off distance you asked about is one of the probing parameters (ZClearance).
You'll want to set it and some others as needed (ex: probe Rate is another you'll want to set).
The probing parameters are covered in manual section 8.4.1

3) once things are set up, the actual use is simple -
a) place the Touch plate on the surface you want to set Z0 for
b) jog the tool over the touch plate
c) Make sure "TLO Active" is in the state you want (either on or off)
d) Click one of the "Probe Z-" green arrows on a probing page

The tool tip will lower, find the touch plate, Z0 will be set Z0 to the bottom of the touch plate (same as the top of the surface the plate is on), and the tool tip will retract the amount you set in the ZClearance probing parameter.

Dave

60

CVI MachStdMill (MSM) / Re: Starting over "the right way?"

« on: September 16, 2011, 08:49:17 PM »

Hi,
I don't monitor this forum very often since all the MSM traffic was moved to the MSM forums.
CalypsoVentures.proboards.com
Please ask your question there - I monitor that site regularly.
Dave