Messages

41

Mach4 General Discussion / Re: mpg

« on: June 23, 2016, 11:16:18 AM »

Either form is OK.  The first form (with the variable named "state") is consistent with the sample code in the original wx4 screen set, so some may argue for consistency's sake use that.  The important thing is that the naming of the function variable makes sense (primarily to you, secondarily to others).

As to the signal script vs load script - it is using BOTH.  The signal script (in the wx4 screen set) simply calls the scripts in the SigLib array that is defined in the screen load script.  The idea (I believe) is to put most of the customized code in the screen load script instead of having some there and some in the signal script.

Also keep in mind that the SigLib scripts get called only on a *change* in the signal, either from 0 to 1, or from 1 to 0.  You can test both for a signal going high/active *and* going low/inactive by including an "else" clause, like this:

Code: [Select]

[mc.ISIG_INPUT0] = function (state)
      if (state == 1) then
         have to figure out what to put here
      else
         -- This "else" clause executes when the signal transitions to the "off/low/inactive" state
      end
end,


42

Mach4 General Discussion / Re: Bitmap buttons left up action

« on: June 22, 2016, 02:07:08 PM »

Simple question, and maybe I'm missing something - why not use the "left down" action and/or script instead of "left up"?  If this is something that you are sure yo never want the user to change their mind and abort the action, then "left down" would execute as soon as they clicked.

Bob

43

Mach4 General Discussion / Re: Mach4 probe settings

« on: June 21, 2016, 10:34:28 AM »

I suspect that this is not a SmartBOB specific issue, but can't say for sure until we know more.

What values have you tried for the probing settings?  And what value is in the "X position" (or whichever axis you are probing) on the "Single Surface" tab of the probing screen?

I'll presume for now that you are probing in the X axis.  The value in the "X position" on the "Single Surface" tab is the absolute X position that is your estimate of where the edge is.  That, combined with the "Overshoot Amount" from the "settings" tab, and the current X position determine the G31 coordinates.  For example (I am using inches as my units):

Current X position is 0.000
Overshoot is 0.0500
Fast find feed rate is 20 (inches/min, a number I number I pulled out of thin air, though 1/3 inch/sec sound reasonable)
Single surface X position is 0.5000 (apparently the default??)

If you click on the "Measure X" button, the probing screen will generate this command: "G31.0 X0.5500 F20.0".  That means it will move at most 0.55 inches (starting at zero, the current X position) looking for the probe touch.  If you enable the Mach4 diagnostics log (go to the Diagnostics menu and select "Logging...", then in the logger window, click on the little right arrow in the upper left corner (looks like a "play" icon), then start the probing motion you can see the G31 command in the log window.

If the current X position is 0.4000, the G31 command will be the same, and you will get at most 0.15" of travel.  If the current X position is GREATER than 0.5000, the probing screen will attempt to move in the negative direction looking for the probe contact.  For example, if the current X position is 0.9000, then the command will be "G31.0 X0.4500 F20.0" (i.e. 0.0500" in the negative direction from the target of 0.5000").

Does this make sense?  If you can't get it working, create a package profile and either post that here (Help->Support->Package Current Profile).

Bob

44

Mach4 General Discussion / Re: change motor counts with lua

« on: June 09, 2016, 11:48:29 AM »

First - did you "copy and paste" your code into your previous post, or did you type it in by hand?  I ask because the word "function" is misspelled in both places.

Ahhh... I missed a small note in the mcProfileReload description - that function can only be called when Mach4 is in the "idle" state so it may be that Mach4 ust be disabled in order for that function call to work.

I tried the m108 script here real quick and I was unable to see any change from it.  The INI file never changed and when I looked in the Configure->Mach dialog, then motor tuning params did not change.  I'm afraid I can't be of much more help. Let's see if anyone else can chime in.

Though I have to ask...  Why are  you trying to change the motor tuning parameters on the fly?

Bob

45

Mach4 General Discussion / Re: change motor counts with lua

« on: June 08, 2016, 09:48:35 PM »

First, why not use mc.mcProfileWriteInt() instead of converting to string and then writing the string?

Try (maybe) mc.mcProfileSave(inst) and (definitely) mc.mcProfileReload(inst) after you write to the INI file.  This function is only available on Mach4 build 2914 and higher.  See the Mach4CoreAPI.chm file in the Mach4Hobby\Doc directory.

I'm not sure if you need the mcProfileSave().  In older Mach4 builds calling any of the mcProfileWrite*********() functions automatically updated the file to disk.  But in Mach4 build 2914 I don't remember if that is still the case.  This changed in build 2872/2914 when the reload call was added.  So the sequence would be:

Code: [Select]

function m108()
   inst = mc.mcGetInstance()
   -- local val = tostring(1000)
   -- mc.mcProfileWriteString(inst, "Motor0", "CountsPerUnit", val)
   mc.mcProfileWriteInt(inst, "Motor0", "CountsPerUnit", 1000 )

   -- mc.mcProfileSave(inst)  -- Uncomment this if just the "reload" by itself doesn't work
   mc.mcProfileReload(inst)
end

Bob

46

Mach4 General Discussion / Re: script and mach 4

« on: June 08, 2016, 02:01:50 PM »

Except... mark4 mentions editing"wxmach" which means he is using the wxMach screen set, not the wx4 screen set.  The two screen sets handle signal scripts differently.  See this post on our forums (step 6, though if you are going to be changing the screen set you really should make a copy of it, as described starting in step 4):
        http://www.pmdx.com/PMDX-Forums/index.php?topic=271.msg1127#msg1127

For wxMach-based screen sets you put the code to handle the button presses in the "Signal Script".  For wx4-based screen sets, you put then in the "Screen Load" script.

The code in the link above does something other than what you want. First, map your two buttons to two of the "Input #x" Mach4 input signals (for example, "Input #0" and "Input #1").   For the wxMach screen set, you want something like this (appended to the bottom/end of the existing script):

Code: [Select]

-- *** THIS CODE IS FOR THE wxMach SCREEN SET, in the "Signal Script" ***
-- Input0 is "cycle start"
-- NOTE: This will NOT run commands from the MDI window.  It will only run GCode files.
if ( sig == mc.ISIG_INPUT0 ) then
    if (state == 1) then
        mc.mcCntlCycleStart(inst);
   end
end

-- Input1 is "feed hold"
if ( sig == mc.ISIG_INPUT1 ) then
    if (state == 1) then
        mc.mcCntlFeedHold(inst);
   end
end
As noted above, this code won't start MDI commands, only GCode files that you have loaded.  If you want to run either MDI or GCode files that gets much more involved if you are using the wxMach screen set.  I would suggest changing to the wx4 screen set, or at least taking a look at the CycleStart() function in the "screen load" script to see what it takes to run either MDI or GCode files.
[edited to correct the "sig ==" test for feed hold]

47

Mach4 General Discussion / Re: Capturing errors

« on: May 29, 2016, 09:32:23 PM »

Yes, call
     local inst=mc.mcGetInstance();  -- Omit this if you already have done this
    mc.mcCntlSetLastError( inst, "Your error message here" );

That will display a message in the Mach4 status/error line at the bottom of the window, and also in the "History".

Or you can use:

  mc.mcCntlLog(inst, "Your error message");

Which will add an entry to the Mach4 log (view it from the Diagnostics menu, select "Logger").

Disclaimer: I am not at a PC with the Mach API docs.  In the plug-in API, there are two additional parameters in the mcCntlLog() call, the file name and line number.  I don't know if they exist in the Lua version, or if they are optional.  I *think* you can pass NULL and zero for these if you don't want or need them, but I'm not sure.

  mc.mcCntlLog( inst, "Your error message", NULL, 0 );

Bob

48

Mach4 General Discussion / Re: Mach4 how to use M62 P0 Command to control Output 0

« on: May 28, 2016, 10:28:19 PM »

I have tried different connections on the pmdx Port#1Pin#1, Port#2Pin16 and 17 but non seems to work.
Further investigation using the diagnostic screen shows that Output 0 Never toggles to On..... No matter of hardware configuration this should toggle right? Im running build 2914 of Mach 4.

I can't speak to the ESS plug-in and whether or how they implement M62/63.  I *think* that signals controlled via M62/63 will NOT have their status reflected in the indicators on the diagnostics tab until the current MDI or GCode file has conpleted.  If I remember correctly, the reasoning was that the Mach4 core does not know when the signal is actually turned on or off by the device.  I am not at a PC where I can test this, but that may explain why the diagnostics tab indicators never turned on.

Bob

49

Mach4 General Discussion / Re: Random Fixture Offsets

« on: May 25, 2016, 03:19:07 PM »

Oops - sorry about that.  I just looked at our plug-in code and didn't check to see if the function was available in Lua.

Bob

50

Mach4 General Discussion / Re: Map Lua Code to ShuttlePro button

« on: May 25, 2016, 01:33:24 PM »

Beware of mixing upper case and lower case in  your function names.  For example, when you define the M3() function you use upper case.  But when it is called from the "in editor" if statement it is called with lower case m3().

Some people claim that the case of the function name and the upper/lower case used in the file name matter.  I was not able to see any effect of upper/lower case in the file name, at least on my couple of PCs.  But I did not test on Win8 or Win10, so I cannot guarantee there ISN'T as issue.  To be safe, keep everything using the same case (I use lower case).

Bob