Okay,  Don't know why I didn't figure it out yesterday while on the machine.  Playing around today, It looks like I have to Catch the speed request inside of SpindleSpeed.m1s.
Just as Dave pointed out.  I think I tried to be smart and failed.  Figured I didn't need to go into SpindleSpeed if I was doing an M3.  Clearly an  M3 (which has a S???) goes through the SpindleSpeed call first and then runs the M3 call.  If the returned value from SpindleSpeed exceeds the current Pulley max, Mach changes it to Max and then runs M3.  I get it.  I knew there was no way that I write my first script and run into some fundamental bug.  I will try to dumb myself down moving forward.
Thanks Guys.

Feeling like the tool change is going to be very manageable.  Been a little nervous throughout the re-wire that I wouldn't be able to complete the changer and would end up with a basic knee mill.  This stuff ain't bad at all once you dig in a bit.

I wish I was at your stage, but still wrestling with the mechanicals, I love the wiring and debugging part

Just an update.  I have the gear change working well.  Its funny, I figured I would start learning the scripts with Gear change thinking it would be much easier than the tool changer.  It actually is more difficult because of the way SpinSpeed and M3/M4 are tied together is not so obvious way.  But it ended up being a great learning experience.

I ran into a problem where anytime I used an "IF NOT GetInBit(?) THEN" statement, it always returned true irregardless of the input state.  Had no clue what was making my programs do silly stuff.  Finally narrowed it down to a plug-in issue I'm pretty sure.  If I use the "IF NOT GetOEMLed(?) THEN", this works as expected so it's not likely a mach issue.  But if I call on CSLABS hardware, it never worked.  A regular "IF GetInBit(?) THEN" statement does work correctly.  I emailed CSLABS support and waiting on reply.  As a workaround, I can do this.
"IF GeTInBit(?)=0 THEN" and this works inplace of using the IF NOT.

So I moved on to the tool changer and found it to be rather straight forward so far.  I am able to orient the spindle with no speed or timing issues straight from the CSLABS I/O.  Tool carosel seems to have no issue landing on the correct tool with the geneva cam setup.  Never really paid attention to how they work and now I get it.  Awesome design.  Instead of trying to land within 1 degree or less, you now get to just land within 180 degrees and you are good.  Clever solution.

So I have it where the Z, Carosel in/out, and Carosel tool select all work in harmony.  I want it to work as close to the original machine as I can.  On power up and Homing, the Haas always homed the z, then x and y and then it would go put the existing tool in the current pocket.  Raise Z to safe and run carosel to tool 1 and load that tool.

I like this and it makes perfect sense to me.  It seems Mach likes to just load up with tool 0 and its up to the operator to not forget to fix this.
So couple of questions:
What would be the best way to add carosel and tool 1 selection when homing all?
Can I eliminate mach displaying a tool zero.  Instead, all tools are 1 through 16.
Thanks,
Mike

Ran into the same thing with the Not GetInBit() just a few days ago whilst trying to write a macro for a friends lathe turret. It has been kind of awkward as I am emailing files  and trying to get things working without actually being able to see what is happening. Hopefully I have it now, ended up using a Do Loop rather than a While No GetInBit.

It brought something to mind however, I seem to recall that If Not GetInput() wouldn't work, that is the call for Modbus input and the CSMIO's use their own internal Modbus so it may actually be Mach that is the problem with the Not

Does the Persistent Tool  Selection option on General Config not work to keep the tool number correct. If I recall it works fine on Mill and half OK on Lathe as it will dump the lathe offset but keep the tool number, but as said Mill should be fine as you call the offsets separately in Mill.


Hood

Thanks Hood.  The persistent tool seems do what I need.
CSLabs got back and is pretty sure it is a Mach issue.  They were able to dupilcate the issue using GetUserLed so it's not just when their hardware is called.  Using the If ....=0 seems to take the place of IF NOT just fine so I'm good.  Wonder if Mach 4 has similar issue?

There is no "if not" bug.

getInBit() and getUserLED() are INTEGER functions which return 0 or 1.

Contrary to (seemingly popular) belief, the integer values 0 and 1 are not 100% equivalent to false and true. (at least not in BASIC).

To use integer expressions correctly in logical contexts they should either be explicitly cast to booleans or perhaps more normally, explicitly compared to the required values. In the second case of course, the comparison itself yields a boolean result, hence no need for casting.

So why (I hear you ask) does getOEMLED() work just fine with "if not"?

Simply because it is not an integer function, it actually IS a boolean function.

The moral of the story? - don't indulge in type abuse - it'll bite you sooner or later.

This makes perfect sense.  I probably made stupid assumption thinking about modbus with coils and registers and then seeing the "bit" in GetInBit.

So I think you are saying that I should never have this:
If GetInBit() Then...

But instead, it should be

If GetInBit()=1 Then...


Thanks, I think this helps alot.  Don't think I ever looked at what Type anything was.  Thats not cool at all.

This makes perfect sense.  I probably made stupid assumption thinking about modbus with coils and registers and then seeing the "bit" in GetInBit.

TBH there's no particular reason that immediately comes to mind why it SHOULDN'T have been written as a boolean function. But tis what tis.

So I think you are saying that I should never have this:
If GetInBit() Then...

But instead, it should be

If GetInBit()=1 Then...

You got it.

But please remember, this is for NON boolean types. If the type IS boolean - please don't write this sort of nonsense:

if someBooleanExpression = false then...

I get it.  Respect your Type.
Thanks

Got a bunch of issues with FEEDHOLD.

So I added a Stop, Cycle/Start and FeedHold switch to my panel.  Started playing around with these to insure they work.

First, issue-  Feed Hold is ineffective at quickly stopping the feed.  Read up on the forum and sure enough, it's gonna keep right on rolling until the buffer on CSLabs is finished.  Actually, it seems more like its going to just coast to a stop some time in the future.  But let me finish.

I started to mess around with 3 different Mach 3 Installations.

Mach 3 On Desktop that nothing has been really confirgured at all.  Not on any machine.
If you run a program, hit FeedHold, it shows a delay and pretends to stop at the point that it coast to a stop.  Press start, it pretends to continue on from that point.

Mach 3 on an actual Knee Mill using an actual parrallel port.
If you run a program, hit FeedHold, it has a significant delay before coming to a stop.  Press Start and it backs up to the last known point which is the last line in the G-Code program.  Works Okay as long as an arc wasn't being executed when you hit the feedhold.

Mach 3 on the Haas using an external motion controller (cslabs)
If you run a program, hit feedhold, it has a "very" significant delay before coming to a stop.  Press Start and it goes to the next point in the G-Code file.  Thats a straight line tool path right across the part.

I get a feeling I already know the answers to my questions but would like to hear it.  My guess, in desktop mode, works like a champ.  On actual machine with parallel port, a semi fix was added to back up and hope for best.  On an external controller, all is lost because there is no "packet control" on what was sent, received and whats remaining.


I have been searching this topic and am quite surprised it has not been more vocal.  The cycle/Start and Feed/Hold are the most used hard switches on a VMC.  Admitteldy, I have had Mach 3 on my knee mill for 3+ years and never really paid attention to this.  On the VMC, its different because I have a Z that is very fast and I have a bunch of different tools with different tool lengths.  Number one thing I use the Feed/Hold for is Z moves on the first run.  I like to hit it just short of contact and do a quick check on the distance to go.  Saves a lot of unexpected (operator/programmer error) crashes and lets you do the first run with moderately fast moves.  Thats not going to happen on the way it works now.  Actually, the way it works now seems to completely make the Feed/Hold about as dangerous as it gets.  Unresponsive and unpredictable.


Really hoping someone has insight.  Have seen suggestions to use older version of Mach.  I'm open to that but would also like to have a clue of what issues I will be facing right out the gate.