Messages

71

Show"N"Tell ( Your Machines) / Re: The Evolution of my Machine

« on: August 14, 2019, 10:42:45 PM »

Thanks, good to know. Wiring, cabinet design and component selection are what I see as troublesome spots most often. Aside from that most that practice due diligence (reading manuals, researching, testing, etc.) usually get on pretty well.

Solid advice on the motion device. There are several good ones and the ESS is certainly in that list. Too often buying the cheapest ends up being the most expensive.

72

Mach4 General Discussion / Re: Jog Speed DRO

« on: August 14, 2019, 06:51:35 PM »

What DRO Code is assigned to that DRO?

73

Mach4 General Discussion / Re: Retrofit masterwood Y coordinates problem

« on: August 13, 2019, 10:13:34 PM »

If the dimensions machined are accurate it sounds like you are not locating in the part accurately. Shift your Y work offset by the amount it is off.

74

Mach4 General Discussion / Re: Creating M-Code to activate Outputs

« on: August 10, 2019, 04:17:38 PM »

If all you want to do is to turn on and off an output from G Code, you should try using M64 and M65 
Look on page 60 of the Mach4 G Code programming manual for mill and router style machines.   
M64 P2   this will turn on output 2
M65 P2   this will turn off output 2

Yup, that is what I was talking about earlier. Forgot they ended up being rolled into Mcodes though.

75

Mach4 General Discussion / Re: The new industrial screens in the dev builds

« on: August 09, 2019, 12:36:55 PM »

Well, it is like this. We maintain the default screens. Users have to maintain their custom screens. The default screens in industrial were changed to be the same as hobby screens strictly to help us keep it all maintainable. I hope this standardization of default things in Mach4 continues. As developers we will change things from time to time. However this does not change anything in your custom screen (assuming of course you have saved your custom screen as something unique/other than a default screen name). But this does not mean that changes we make will not break your custom screen. It just depends on what we change. Take for example our recent move to lua 5.3 from 5.2. This was a necessary change in Mach4 but it may well have broken some users customizations. This is why it is so important to keep good records and copies of your customizations. You may need to edit them any time you update. Naturally we weigh it all out and try to keep such changes to a minimum but it does happen. Just the nature of progress.

Yes, the old Ind. screen should be fine in the new build. But at some point it won't be. Anyone can still use it but it is theirs to maintain if they want to keep using it.

76

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: August 09, 2019, 12:11:59 PM »

There are a couple of other issues with the software  - it doesn't seem to remember any of my settings (in the plasma screen) between sessions - I have to manually enter them each time - not a big deal - I guess this could be due to it being a dev version.

No, that is not because it is a dev version. It shouldn't be doing that. Not sure why yours would be. Can't repeat it here. If you started with a clean install and the default profile and screen I see no reason for it. If you have anything custom start looking at that.

The THC module creates the registers and sets the relative ones to persistent. You should be able to launch Mach, set all the variables, close Mach and launch Mach again and all the variables should be whatever you set the variables to in the last session. If that isn't happening you have a problem unique to your setup. Custom script, screen, corrupt machine profile, antivirus, etc.

Sometimes the program stops after a pierce saying the a the OB motor took to long to move - 4 seconds (I'm para-phrasing here - I do not have the exact error message)... seems to happen after about 20 or so profiles in a single file. Agh - lots a messing about trying to reset/re-start the program and trying not to lose position.

When it does this look on the Machine Diagnostics tab. What does it say machine state (little lower than midway down on left side) is?

You can also try to make the the time longer by adjusting the Diagnostic, Regfile, iRegs0/nf/thc/MoveTimer value. 4 is the default value and stands for roughly 4 seconds. Try it at 8.

77

Mach4 General Discussion / Re: add image

« on: August 09, 2019, 11:28:15 AM »

Yes and yes.

Operator, Edit Screen, Screen, Manage Images, Add

To change the image of a screen entity define the image of whatever property it is relative to using scr.SetProperty. All property names are visible in screen edit mode when you click the entity.

scr.SetProperty("SceenEntityName", "Bg Image", "MyImage.png")

or

scr.SetProperty("SceenEntityName", "Image Up", "MyImage.png")

78

Mach4 General Discussion / Re: Button script

« on: August 08, 2019, 10:44:34 AM »

No problem, i understand. But do yourself a favor and go ahead and do it right while your doing. If not you will spend more time doing it. Likely much, much more time.

Learn how to do it right for one and you know how to do it right for all.

79

Mach4 General Discussion / Re: when to use rc = ?

« on: August 08, 2019, 02:35:12 AM »

Hi,
ideally you would use rc (return code) on EVERY API call.

Lets take a typical Lua API:

hsig,rc=mc.mcSignalGetHandle(inst,mc.OSIG_OPUTPUT23)

This API requires two parameters (or inputs if you prefer the term) namely an instance number and a number identifying the output
signal for which you want a handle. Note that mc.OSIG_OUTPUT23 actually evaluates to a number.....the text string is called an 'enumeration'
and is done that way because humans remember names better than numbers.

This API has two returns, one is the handle we wanted but also a return code.

When the Lua function, in this case mcSignalGetHandle(), is returned it returns values in the form of a stack. The stack is read from the lefthand most
entry.

Thus:
hsig=mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT23) is perfectly OK. The variable hisg will hold the correct value after the call has been executed.
the variable rc will be on the stack but if you don't read it thats OK.

However:
hsig,rc=mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT23) is also perfectly OK. The variable hsig will have the required handle AND rc will have a return code.

Most of us don't bother with return codes and we consequently get a lot of code errors without understanding why. Expert programmers read return codes EVERY
API call and they have far fewer crashes.

I myself are somewhere in between, certain APIs which give trouble I test completely, others I don't bother.
Also if you write code for a newcomer to Lua then including all the extra code just to read return codes often confuses the newcomer which is definitely
not helpful..........but tends to start a bad habit, namely that of not reading return codes.

Craig

Well said, spot on.

The default screens and profiles are all set up to take advantage of the included mcErrorCheck (I think that is the name) module.

80

Mach4 General Discussion / Re: Button script

« on: August 07, 2019, 06:57:25 PM »

The sleeps are really not for the code, they are for a delay as the outputs are activating air cylinders and we can not have the next output activated till the cylinder has finished its stroke.

If that is the case then you should have sensors that tell you when the cylinders have finished their stroke. And the way to hold it up until it does is to use the mc.mcSignalWait api and wait for that confirmation signal to go to whatever state it goes to confirming it has finished it's stroke.

Put some checks in you macro to find out where it is breaking.........
mc.mcCntlSetLastError(inst, "Step one finished, cylinder 1 should be retracted")
mc.mcCntlSetLastError(inst, "Step two finished, cylinder 2 should be retracted") etc.