Hello Guest it is April 27, 2024, 08:56:50 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Screwie Louie

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 »
131
Mach4 General Discussion / Re: G31.1, G31.2, G31.3 working?
« on: May 30, 2015, 02:16:18 PM »
This is actually pretty good. It demonstrates the following functions:

1. How to create a frame and panel for GUI purposes
2. How to open a file and define the input parameters when the file is appended
3. Tell the input of the probe where to go (ie, the file path above)
4. Close a file

What is not demonstrated is the code to actually move across a coordinate plane and collect the data. G01 moves in exact stop mode. This code uses the mc.Motion functions to interface with the core. I think G31/G31.X scripting is done by motion controller plugin OEM and the core because electrical latching signals on the PCB itself. I think we can code around this...specific code for your particular requirement.

We can use poppabear's switch case statement example or just use a signal table where the input would be high/low signals and a function call ie mc.MotionSetProbePos()...to emulate G31.X

132
Just copy & paste in the mcLua editor and Run or use it in a button script. Couldn't get the .mcs file attached.

Demonstrates variable scoping, using 'for' loops, return codes, and 'goto' statement.

Run it first. Then deref your axis and run it again to see if the script picks up that your axes are not homed. Then read the code remarks.

The functions are only examples of what we can do. I just did this as a learning process.

--josh


--comments on--
Code: [Select]
--local variables are associated within this script only
--you can define global variables in the Screen Load Up script
--variables pass through all functions in this script
--Define local variables and initialize

local inst = mc.mcGetInstance ()                                                           
local rc = 0
local remark = ""

--using a 'for' loop to find what axes are enables
--this example is just written a different way, it is harder to read but faster to write

function countEnabledAxis ()
    local j = 0; for i=0, 11 do; if mc.mcAxisIsEnabled (inst, i) == 1 then j = j + 1; end; end
    wx.wxMessageBox ("You have " ..j.." axes enabled."); return j
end

--using a 'for' loop to make sure the axes are homed before executing movement
--the number of iterations or loops is equal to the number of enabled axes only
--we then check to see if the number of axes is homed is equal to number of axis enabled, kinda like a signal verification check

function safetyCheck1 ()
    local var = 0
    var = countEnabledAxis ()
    local j = 0
    for i=0, var do
        if mc.mcAxisIsHomed(inst,i) == 1 then
            j = j + 1
            wx.wxMessageBox ("Axis " ..j-1 .." is homed")
        end
    end
    wx.wxMessageBox (var .." axes enabled\n" ..j .." axes homed")
    if j ~= var then
        return "Not all Axes are homed.", false
    end 
end

--if applicable above functions can be loaded into the Screen Load Up script to return a value to your button script
--functions in the Screen Load Up script are accessible to all button scripts
--visualize function main(), call for your defined global safetyCheck function and then execute main function in your button

function main() 
    wx.wxMessageBox ("All is good to execute some screwie louie custom button script.")
end

--this is the point at which the script actuall starts
--the first thing is to start a safety check, this check can be anything you want it to be
--if the machine is not where you want it to be the safety check will return false

wx.wxMessageBox ("Being safety check.")
remark, rc = safetyCheck1 ()
local var = rc

--safety check returns a message 'remark' and a return code value
--just want to demonstrate what we can use return codes for and the 'goto' statement
--if the machine is not where we want it, skip executing the main function of our button script and goto finish line

if rc == false then wx.wxMessageBox (tostring(remark)) mc.mcCntlEnable (inst, 0) end goto finish
main ()


::finish::

--this let's use execute our current script in the editor enviroment for debugging puposes
if mc.mcInEditor () == 1 then main() end

--comments off--
Code: [Select]
local inst = mc.mcGetInstance ()                                                           
local rc = 0
local remark = ""

function countEnabledAxis ()
    local j = 0; for i=0, 11 do; if mc.mcAxisIsEnabled (inst, i) == 1 then j = j + 1; end; end
    wx.wxMessageBox ("You have " ..j.." axes enabled."); return j
end

function safetyCheck1 ()
    local var = 0
    var = countEnabledAxis ()
    local j = 0
    for i=0, var do
        if mc.mcAxisIsHomed(inst,i) == 1 then
            j = j + 1
            wx.wxMessageBox ("Axis " ..j-1 .." is homed")
        end
    end
    wx.wxMessageBox (var .." axes enabled\n" ..j .." axes homed")
    if j ~= var then
        return "Not all Axes are homed.", false
    end 
end

function main() 
    wx.wxMessageBox ("All is good to execute some screwie louie custom button script.")
end

wx.wxMessageBox ("Being safety check.")
remark, rc = safetyCheck1 ()
local var = rc
if rc == false then wx.wxMessageBox (tostring(remark)) mc.mcCntlEnable (inst, 0) end goto finish
main ()
::finish::

if mc.mcInEditor () == 1 then main() end

133
by the way, I just changed my name from 20,000 Axes to just my first name....just so your are like "who the heck is this guy?"

134
Mach4 Videos / Re: Mach4 - Arduino and Touchscreen
« on: May 30, 2015, 04:35:34 AM »
yah, I know. The PCB boards we are experimenting with are manufactured in China. I just went off the cliff there. Off topic and I promise not to bring it up again.

135
Mach4 Videos / Re: Mach4 - Arduino and Touchscreen
« on: May 30, 2015, 04:31:43 AM »
Dude, you are totally opening up a world in which we can program and use Mach 4 's core engine for customization on a very small footprint. You are beating me to it! haha! I'm glad. It's the love for the game right there. The experimentation and the excitement of accomplishment...plus the frustration, trial and error, and cost...but funk it. It's about learning, expanding our knowledge and sharing it. Mach3 boards have good Audrino threads in it too. You can start to see common themes and patterns. Once they are identified, it doesn't matter what language something is programmed in. How do you think people can talk five or six different languages? They are good at pattern identification and association. It's only a matter of time before Mach 4 is broke wide open and is truly customizable. I am not talking about cracking Mach 4. What I am talking about is the potential of Mach 4 to be a PLC interface that everyone can afford and tailor to their specific requirement. It's pretty cool actually and exciting. Knowledge, experience, skills, abilities...it is those characteristics we need to share. Other than selling our foreign competitors the licensing fees to our patents and property rights at minimal value while they turn around and buy US debt and resell their products from our designs at a higher value. But, it is cheap you say? How cheap does our investment in our future become? ....FML, i just went into left field. Sorry.

Keep on rockin Daz!

136
Holy sh!tB@lls batman!! That is freakin awesome! ?Good looking out Tim. Thanx for letting us know if we ever encounter that issue!

--josh

137
yah, Lua is an extension of C++ and the I'd bet you the core is written in C++. Those functions your are looking at are from the the core in C++. Even though we may still apply those parameters we do not know how they are implemented. That was Simpson36's point when he asked for open code or if we already have it...then, where is it? we can us MC_JOG or something like that..it is given to us in the api. Pappabear also references C++ parameters to pass to functions in his posts.

Basically, all I am saying is the core is written in C++ and we are give Lua to interface with the core as to protect it from corruption and counterfeiting. Simpson36 is right...and Daniel is right...both statements have a specific application. It just depends on your requirement. Simpson36 is leading you in a good direction....but, you have to find the answer. I mean he doesn't know exactly your specific requirement / hardward specs / interface/ etc...Daniel is giving you straight up code to fit a certain situation. Does that situation apply? I don't know. But it is two different perspectives. I really appreciate the different views that are given and your initiative on just tackling it. TAKE MACH 4 FOR a RIDE. Don't let Mach 4 take you for a ride. Thank you all for your contributions and time. I think this is wonderful and is a knowledge base worth preserving.

138
Tim, if you are still having syncing problems look at the mc.Motion functions in Mach4.api for direct control over the motion controller ie. mc.mcMotionSync(inst).

Just a thought. Haven't played with it yet.

-josh

139
Now that took some time! Congrats Tim. You are almost there! Best guess to deconflict actions....

Event signals are mapped to a table reference of functions by input name in the PLC that execute would GUI type scr. calls to change the property values of that button/display to reflect your input. Considering your GUI environment matches your physical hardware binary/latching/electrical characteristics and vice versa.

GUI actions are mapped to executable functions within the PLC. Not hardware actions to GUI or GUI to hardware. The PLC is your interface.
That may take care of some syncing issues but the real issue as Simpson36 states is resolution of resource conflict. You may be using inputs from both
the MPG and the GUI to the exact same memory space resulting in syncing issues again, latency, or worse freeze-up. But shoot, I'm just a newbie trying to code auto tool zero without using G31. You guys are on like expert level.


140
Mach4 General Discussion / Re: G31.1, G31.2, G31.3 working?
« on: May 29, 2015, 04:34:52 AM »
Well shoot, we can code it without G31 theoretically I think. G31 just makes life easier on us by automatically storing the coordinates in a file upon contact, then retract and incrementally jog by say 0.001, move in a pattern by same amount until contact, write to file, retract and repeat unto ~= contact while moving across a user defined coordinate plane. How did Mr. Barker do his probing video on youtube with Mach4? Bet you he just coded a script for execution or maybe that's why we only see a short video clip...I'm near done with code for auto tool setting without using G31. Well that's my intent anyways. I know tool setting is just one point. But if you succeed in accurately reproducing that coordinate over so many instances then all is needed is just to expand the code for top of material across your table to produce a file. Then...import it to Solidworks or Rhino 5 for conversion, alterations, toolpath and back to Mach for production. I know, it's sounds easy but it's not.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 »