Topics

1

Mach4 General Discussion / Mach4 cnc program min/max values

« on: April 13, 2019, 03:33:06 PM »

Back when I used Mach3, I used to check the travels in my programs for obvious travel issues with the min/max values mach showed.  It was helpful as most of my programs run once only so there's always a bit of anxiety when pushing the go button.

When I moved to Mach4 a few years back I tried using the feature there, but never could get my brain around something in the x, y, z displays.  Yesterday I decided to give it another try.  Think I've sorted out the values are all in machine coordinates and for X and Y, the math computes to reflect my programs.  Z however is way out of range.  This morning I took another look and seen that if the Z values were correct in the min/max dro's my mill head would travel below the table by a rather large amount.  An example, the last program I checked in the min/max readouts should have showed me a combined z travel of right at 3.9".  Instead it reflected a total z travel of over 10".  I reloaded a few programs I've already made parts with and I see the same thing.  The programs didn't do what the z min/max values say.

If it just reads the program and reflects the values from that, there is a problem I'm not understanding.  Is it possible it takes tool changes into account?  That's not helpful to me in evaluating a program if that's the case.  I can't get the math to work out though if that's the case, and I don't know why the Z tool change position in my M06 macro would be included in those travel values.  Anyone use that feature and have an understanding of it?

Regards
Bob

2

Mach4 General Discussion / G43 moving spindle down before moving to correct Z location

« on: September 08, 2018, 02:14:45 PM »

Had this problem for some time, enough to stop doing tool changes.  But i need to fix whatever is wrong and get back to programmed tool changes.  I'm running Mach4 V4.2.0.3233 and an ESS.  I've moved to BT30 tool holders in my spindle on a vertical mill, but do manual tool changes.  I'm using the unmodified M06 macro and that seems to work as it should, I program x, y and z moves to move the spindle up and over for tool changes, not relying on movement via the M06 macro.  I have T set as tool in use in Mach options and tool changes go as expected. I also have a fully populated tool catalog with all the proper lengths for all my tools as measured by my off line tool pre-setter.  Once the G43 has moved the spindle to the height as specified by the tool heights in the tool catalog, they are all positioned correctly.

However, after the tool change via M06 and hitting cycle start to signify the tool has been changed, the G43 causes a rapid downward movement to near my current Z0, then quickly back up to accomplish the tool height change.  This occurs whether the new tool is longer or shorter than the last.  This does not happen when all this same code is keyed in the mdi and ran from there, the only movement from that is to shift the spindle up or down according to the change in tool height from the previous tool.

Today, I'm so spooked by programmed tool changes, I'm probably taking them out again so I can cut parts.  But this ought to be solvable I'd think.  I have come to the conclusion it's not related to the M06 macro or any lines of code prior the G43.  My G43's are always the same format...G43 Zx.x Hx, they are always added by my programming software, most always follow an x-y move, but lately I've been moving the G43 prior to those moves to avoid the cutter rapiding into my part.  And yes it will do that for every tool change unless I take some action, mostly adding in a x or y move to get the part and vise shifted out of harms way.  Moving the z up higher doesn't help.  Just seems to give it more time to accelerate into the part.

Hopefully this descriptions clear enough for a good understanding of my problem and hopefully too, someone has seen and conquered this problem.  I can share whatever might be helpful if requested.

Regards
Bob

3

Mach4 General Discussion / Integers defined

« on: June 06, 2017, 02:11:50 PM »

Hi all,

I've been messing about with my screen script for many months with some successes.  But some failures at the same time.  One of the things that stumps me a lot is in the CoreAPI, the descriptions of the parameters at times state an integer is required.  Take mcJogSetInc for example, the axisID is stated to be an integer.  But in th usage example given at the bottom of that particular page, it states "mInst, X_AXIS, .010".  Now just to make sure I was thinking correctly, I actually looked up the meaning of integer.  I found what I thought it to be, "a whole number; a number that is not a fraction".  

So just where are these integers explained in the CoreAPI?  I never have found any in the looking I've done.  I actually have this function working in my script, but it was mostly by trial and error trying to figure out what exactly I needed to have in that portion of the statement.  I ended up using the motor numbers and got things to working.  When I tried using X_AXIS there, I got an error stating basically a number was expected and it didn't get it.

Is there a listing of the integers used in these portions of the functions somewhere?  I hate for things to be a guessing game, but that so far has been the only way I've got much of this to work.  Another example would be the mcJogSetType, again it states in the LUA syntax for that function number, number, number for the three parameters and for axis it specifies an integer as it does for the type.  But in the usage at the bottom of the page is has no such thing and using that results in an error, again with it expecting a number in the second and third portions of the statement.  

So unless I'm completely daft, I think I need to supply an integer for these statements.  Is this something I need to make an assignment for somewhere?  I didn't for the axis in my statements to set the jog increment value.  Maybe I got lucky using the motor numbers there, I got no clue.  And I really don't like operating like that.

Thanks for any advise you might have.
Regards
Bob

4

Mach4 General Discussion / Mach4 M6 Macro problem

« on: April 07, 2017, 09:30:02 PM »

HI,

Been working on getting tool changes to function in Mach4.  I mostly have tool changes working from the MDI, but there’s oddities there.  In my written programs though tool changes mostly get jumped over.  Initially I found there was no m6 macro in my machine profile.  Simple enough to solve, but I had gotten a few tool changes to work in the MDI without there being a macro.  I shrugged that off and plowed ahead with the one I copy and pasted in.

Testing tool changes in the MDI became dependable except for the number in the tool # dro.  It seems to drag up the last tool number I had when I shut the system down earlier.  An example would be I had tool 19 mounted and had applied a g43 for that tool, then shut Mach down.  Next time I start Mach, I might have tool 19 displayed and I might not.  But now I want to mount tool 1, so I command a T1 M6 in the mdi.  If tool 19 was displayed in the dro at that time, mostly it will change to tool 2.  If I hit cycle start one more time, then the dro will finally display tool 1.  That’s the MDI oddity.

In my programs though is where it starts to really break down.  On initial launch of the program, it may stop at the T# M6 and allow me to change tools, or it may jump right over it.  This occurs with no change to the program, it’s for testing tool changes with slight x, y, z moves in between.  And of course if it jumps the M6, it has the wrong tool for the upcoming G43.

But if I succeed in getting the first tool changed at the first M6, I’ve never gotten the second M6 to halt the program and allow a tool change.  It just gets jumped.  Then I abort the test.

My system is running Mach4 build 3233 and an ESS with plugin 193.  I’ve been reading all I could find on tool change problems for the past few days but not gotten to the point I think any of what I’ve read might be the cause for my problems.  But that could be all on me not making a connection.  I do have a question on one bit I read yesterday, what is the sim plugin in the plugins folder?

Here’s the m6 macro I’m using for testing.

5

Mach4 General Discussion / Multiple inputs in LUA script

« on: October 10, 2016, 06:40:51 PM »

Hello,

Been messing with Mach4 and trying to get my console switches to all work using LUA scripts.  These all operate through my modbus devise.  And that portion of things work fine, or appears to.  Let me be very clear here, I know pretty much zero about LUA.  But by using examples and lots of trial and error, I have 15 of my switches working now after a few weeks of effort.  One switch is kicking my butt and the other 4 are completely over my head.  The 4 in question are rotary switches that use various pin combinations for each position. 

I stumbled in to poppabear's script somewhere that seems to deal with multi inputs for a function.  It shows 2 inputs, but for two of my four switches, I have 3 pins each.  So me, being simple minded, figured if two were good, then adding a third should be no problem.  Here's the original I started from:

Code: [Select]

local Input14 = 0;
local Input15 = 0;
local Input17 = 0;
local hSig = 0;

hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14);
Input1 = mc.mcSignalGetState(hSig);

hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15);
Input10 = mc.mcSignalGetState(hSig);

hSig = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15);
Input10 = mc.mcSignalGetState(hSig);

if ((Input14 == 1) and (Input15 ==1) and (Input17 == 1)) then
    local inst = mc.mcGetInstance();
    mc.mcCntlSetRRO(inst, 100.0);
end

All the pins in the modbus reflect the values as I have them stated, but I get no response in Mach.  And the script debugs with no errors.  I'm guessing here that I'm missing a lot of statements to make this work.  This is just for one of the switch positions, but i figured that if I got one, I may be able to get the rest.  And this is really the easiest of the 4 rotary switches.  The others get more complex, one for jog control type and increment value, one for FRO and one for SRO. 

The one switch that has what seems like good script is the cycle start function.  Seems to me the scripts I'm using for Enable, single block and the like should work for cycle start.  But I get nothing when trying to operate the switch.  The others with that same scripting work fine.  I used 1 as the variable, did I guess wrong there?

Any thoughts on how to get over this hump?  I'd appreciate the help.

Thanks
Bob

6

Brains Development / Brains writing wrong values to DRO's

« on: March 06, 2015, 01:40:18 PM »

Hi,

I've been working on getting a new mill console connected and talking to Mach3 through a CubeLoc modbus card.  Everything through the modbus works as it should and all the different signals all get fed to my brain files.  The rotary switches I used are binary, that is to say they have single or multiple pins being contacted at the different switch positions.  It took me some time to figure out how to deal with the binary values moving from the switch, to the modbus, to Mach and finally to the individual brain files.  But I got there eventually.  All the binary is dealt with directly in my brain files, the rest of the system just sees it as the individual pins are either on or off.  And for the most part it all works like it should.

But I got one or two small problems I can't seem to understand what's happening.  In my feed rate override brain, I had to keep each brain file to only four switch positions each brain.  So I ended up with 5 individual brains for the 21 positions of my switch.  The spindle speed override is similar, but I was able to have five switch positions in each brain for a total of 3 brain files for that function.  That took some time to figure out what the problem was, but in the end the brains were just too long.

Some more history first, I got both of those switches working along with the rapid override switch some days ago, only to find that the correct percentage number would only get dropped into the corresponding dro while the switch was being turned to increment the value.  If the switches were turned to decrement or decrease the values, the values would be whatever the lowest switch setting reflected or a zero.  I could stop decreasing the switch positions wherever I wanted and go the other directions and the correct values would be displayed again.  I corrected that problem this morning by adding an "or" gate or lobe as shown in the brain pics I've attached.

But now that I have most values being dropped into the dro's correctly, I find that a few won't display the correct value in the dro's.  The brain shows the correct value, but the dro will just show a 0.  The ones I'm finding fault with are either the first or last switch position in each brain, but not across the board.  In brain #1, all four positions work correctly no matter the direction the switch is being turned, in brain #2, the top (63%) won't display anything other than a 0 while the switch is being incremented but works correctly while being decremented.  And in the same brain file, the bottom position (100%) will display a 0 while the switch is being decremented, bt works correctly when it's incremented.  In brain #3, the bottom position (150%) displays a 0 while the switch is being decremented but is fine with it being incremented.  Brain #4 works correctly at all switch positions just like brain #1.  Brain #5 has a problem with the top position (212%) with the switch being incremented, again displaying a 0.  But if decremented, the correct values is displayed.  These are all feed rate override brains and that's what the pictures reflect.

On the spindle speed override brains, I have two that display incorrectly with the switch being decremented and those two are bottom rungs in the individual brains.  All of them work correctly while the switch is being incremented.

Then one other brain is really throwing me for a loop.  It's the rapid override brain.  It only has 4 positions in it and all work correctly except the one that should reflect 75%.  The brain is made similar to the feed rate brains and the brain actually displays the correct percentage at 75%.  But what gets dropped into the dro was 91, not 75.  So I messed with this some this morning and only got more puzzled by it.  It seems I can change the 75 to 60 and it will display correctly in the dro,  61, 62 and 63 likewise.  But if I change it to 64, it will start to display oddly and show 89%.  I got no idea what to think about that problem.

So, I thought I'd ask the experts for some advise to see if anyone had any thoughts on how to correct these small problems.  I can use like it is, but I'd rather they work as they should.   Pics below.

Thanks for looking
Bob

7

Modbus / Modbus testing

« on: August 16, 2014, 06:22:07 PM »

Hi,

Long time reader, first time poster.  Been running Mach for years using MSM screen set.  System is running well on Win7 32 bit.  Decided I wanted to introduce some hard wired switches to control Mach's functions from button pushes, so I bought a Cubloc Cubase64M modbus board.  And honestly, I'm not a computer guy, an electronics guy or a basic or ladder programming guy.  But I got the board working in ladder logic, tested with a toggle switch and an LED hard wired to the in and out pins, then tested in Cube Studio by changing switch styles to see the little led's on the board go on and off with my changes.  Feeling good at that point.  My settings that I downloaded to the board were com1, baud 115200, 8-n-1 or 8-1-n (however that goes), slave address 1, RTU.  All of this was from spending lots of time reading here and other places to get the knowledge to get that far. 

Using the same 1:1 cable I got with the Cubase board, I swapped the serial cable to the com1 port on the cubase board and launched Mach.  Made the settings in Gen Config for the serial port using the numbers from above, then in ports and pins selected use modbus and modbus plugin. Restarted Mach to let the changes take place and went to setup my modbus configuration.  Making the same settings as those I downloaded to the board, I get no error returned when selecting modbus run.  I setup two configs, one for outputs and one for inputs to get me started.  Applied the changes and went to test modbus.  This is where I get nowhere.  I open the com port and get no error message which seems like a good thing.  But I certainly can't seem to get any response by reading the registers, coils or any other selections there.  I've changed the startc and number of coils all over the place trying to get some response in that window.  I get a timeout message and that is all.  I can hit the digital format selection and get some numbers for the total number of coils I input in that box, but the never change with me using the toggle switch I've wired to the board and in my mind I should see a difference between on and off on that particular pin.  Maybe I'm wrong there though.

I've been through all the settings a couple dozen times now the past two days and get the same results in the test.  I've changed the timeout time up to 500ms and down to 100ms.  Never any change in the test window.  I've watched the videos and read a ton on this, and it seems like my settings are the same as what I've seen in them.  But my results aren't like what I witnessed on the videos.  I'm thinking I need to get some response in the test window before I can even worry about seeing if my brains will play with the setup I have on the cubase board.

So, I'm looking for some advise to get past the failing testing I think is happening.  I've been telling myself it's some little setting I've missed, but honestly, there aren't that many to make.  I've read of guys here who had the same problem and I followed the advise given them back then with no success.  One other thing that bothers me is the serial monitor function tells me my "serial is not enabled-go to ports and pins and enable it-then restart Mach".  Does that function even work?  Far as I know there is only two settings that need to be made there and I've made them...many times.  I've lost count how many times I've restarted the pc and Mach, but lots.  I tried the com0 port on the cubase board with the same end results, tried it with power on the board and with the power switch off.  No change which I thought odd.  Power, by the way, is from a 24v wall wart to the round power plug on the board.  Nothing I do seems to get any action other than a timeout on the test screen.  Feeling late today I'm wasting my time with it.  I certainly don't know if this is something incorrect in my Mach settings or something in my statements in Cube Studio, but I do think the pins are all active in ladder and Mach will return some data if I force it.  So I think Mach can read the data on the board.  It's like Mach doesn't even care to take a look at it. 

Thanks in advance for any advise anyone might have to offer.  Sorry for rambling, but I never learned to talk in shorthand.

Bob