Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Screwie Louie on May 27, 2015, 03:10:11 AM
-
Hi folks,
I'm Josh...new around here. I've read a lot on this forum, built a machine, immediately jumped from Mach3 to Mach4 and have been working Lua a bit. Currently, I have a signal library built in the screen load script to watch for ISIG_INPUT0 events that will stop the axis from moving (Gcode cycles and jogging) from the basic if statement in the signal script. This works. Because G31 is not supported by my hardware yet I am trying to find a work around with programming the AutoToolSet button. The issue I am having is that the signal library is not recognizing the mc.mcCntlGcode...calls to stop the axis from moving when I code in Lua the button scripts. I think that screen scripts are different than mCode scripts from an interpreter standpoint that load into a different stack/buffer?.?.?... Anywho, any recommendations on how to say the signal library can recognize a call to mc.mcCntlGcodeExecute(inst, "G01 X...Y...Z..F.../n") and recognize an input signal mapped to mc.ISIG_INPUT0 in the signal library to stop the axis? Also, for kicks, if I call mc.mcCntLoadlGcode or string or file, how do I get that to execute? mc.mcCntlEnabled(inst, 1), mc.mcCntrlCycleStat(inst) doesn't execute the string (I've also tried incorporating input/output handle/get/set state function calls in the algorithm). I think I am missing something easy here...I am just asking for some direction and I can take Mach4 for a ride :o) I pretty much memorized the calls get/set/do from the down and dirty Lua pdf, scripting manual, pound variable list, signals list, the Spaced Out Lua reference (that was awesome!), Mach4 API, Lua Calls, etc. (yep, there is a reason why I am divorced :o) I can't remember "her" birthday but sure as ********* can remember programming function calls! Hope to hear from y'all and promise to share any code that may be relevant to new users coming from Mach3. After all, Mach 4 Hobby users are the beta testers for NFS. Great business strategy btw...crowd source beta testing...at a little cost. But, I've learned so much that it's okay with me and am glad to become apart of the community. Now...if I can cut my first part before I am 100 yrs. old...reliability, repeatability, and accuracy; it is computer numerical control for a reason, lol. Yes, I've learned Gcode sequences too, but the beauty of Mach4 is combining Lua and Gcode to execute a block. The potential capabilities are pretty darn good. I just need a strip map to let screen calls and mCode macro calls communicate with global function / reference tables and the signal script. My two cent...ok, may three cents...
-josh
-
mc.mcCntlCycleStart(inst)...not mc.mcCntrlCycleStat(inst), I know how some can be picky but woodfordReserve knows forgiveness!
-
Got a theory (well, another avenue of approach)...stay tuned.
-
--yep figured it out using conditional repeat/until structure as a timer based on a false signal condition, break when true
--only destroyed both my digital probe and tool setter in the process. The cost of having fun.
--this way I can start a jogging / probing routine without G31, now onto the easy stuff. the more I realize the more I think Lua was used just to create a series of function calls and variables that are just mapped Gcode blocks inside those functions and the variables are are mapped to #var, the power of G65/G66. Ok, I'm just talking to myself now.
function workingAutoToolSet ()
local mInst = 0
local rc = 0
local inst = mc.mcGetInstance (mInst)
local gCode = ""
local hSig = mc.mcSignalGetHandle (inst, mc.ISIG_INPUT0)
mc.mcCntlEnable (inst, 1)
mc.mcJogSetRate (inst, 2, 10)
mc.mcJogVelocityStart (inst, 2, -3)
repeat mc.mcCntlSetLastError (inst, "Approaching tool setter")
until mc.mcSignalGetState (hSig) == 1; mc.mcJogVelocityStop (inst, 2)
end
--[[
gCode = "G0 G28 Z0.0\nG1 G53 Z-4.0 F5.0\n"
mc.mcCntlMdiExecute (inst, gCode)
end
if mc.mcInEditor () == 1 then workingAutoToolSet() end
--]]
-
you can use fanuc macro b as well most of them work like this one I have tried it worked fine, disclaimer use at own risk
G49 (Cancel TLO)
G58 (Switch to work offset G58)
G0 X0 Y0 (move the tool over the toolsetter)
G31 Z-10 F150 (probe tool down till it touches the toolsetter)
G10 L1 P1 Z#2002 (set the tool length offset value to the G58 Z position where the probe tripped)
G0 Z5 (move up to safe distance)
G54 (reapply old work offset coordinate system)
G43 H1 (apply new TLO for tool 1)
if I have time I might try your one
-
thanx for sharing! I've seen you post that earlier. My motion device doesn't support G31 probing commands yet.....hence trying to find a work around. I liked your reference in the bug report pointing to another thread about mcCntlGcodeExecute vs. mcCntlGcodeExecuteWait vs. mcCntlMdiExecute. It help shed some light on the applicability of when to use each function call depending on the circumstance.
-
before you try it....that is just the start of an auto tool zero function. The code written only tells the Z axis to start jogging at a specific rate in a specific direction until it comes in contact with the tool setter, table, or top of material. The stop jogging command is triggered by my input signal through a conditional ~loop.
this is just one step in the process. one block sorta say. I can execute Gcode and move around in a button script. what I cannot do is execute Gcode and have my probe trigger a mc.FileHoldAcquire, or feedhold and any kind of stop movement command. I can only achieve this by using jogging commands and using time with a conditional loop to stop movement because I do not have the capability to utilize G31.
-
workingAutoToolSet() => work in progress!!!! arghhh.....bad way to name a function, how do you edit your own posts? I don't want to confuse anyone.
-
better yet, how do you delete your own posts? I talk to much on here...
-
all post are time limited I think its 30 mins after you post you have said its not finished so that's enough have you seen the M4 scripting manual its in here http://www.machsupport.com/help-learning/product-manuals/
there is a tool height probe thing in it, I have not tested it my self, what hard wear are you using
-
Hi Dan.
yah, I've dove into it. It is a wonderful insight on how we can create user tables, save and clear current data -> execute our tool change at our own defined position -> recall our work offset position, G54, axis coord, etc prior to tool change data, and begin working again, etc. Same familiar concept; just in a new language. The code is fast. I mean really fast and with Lua we get an easy & customizable user interface that we can tailor to our liking or program for our specific requirements. (Now, think of industry...requirements generation, the specific knowledge to comprehend, understand, and program cnc machines to achieve those results. I am not talking video games now. I am talking about physical material being manipulated into what is required for a specific function for a capability for the masses. What Mach4 allows us is a base / core / platform to create a package for industry that is tailored to their specific needs. They had to do this because of competitive markets, competition, and not to mention it is just a smart move in order to grab a market share of industry. That is the beauty of it! For the hobby user, the hobbyist can write a macro or two and sell it for $1-$5 maybe to the general public through paypal and instant download. "Hey Mach 3 had this function, I like this function. Where is this function? What...? I need to learn coding? Forget that. I can afford $3 to get my function back"...So now Mach 4 has given opportunity to hobbyists to offer their time and effort for programming CNC functions...that through the Mach4 platform and motion control devices should give you exceptionally better real time response. Does this matter to the hobbyist? Maybe, maybe not. Hey I like it. But for industry, this is huge. This is not Haas and proprietary software. Mach4 is a platform tailored to execute several axes of machines, at the same time, in different coordinate planes to reduce time and cost and improve efficiencies that is truly affordable. You know what's funny? We are talking about Lua wx libraries for user interfaces that were created in 2002, Lua which has been a popular user interface programming language for a decade, and a CNC software platform that has been in Beta testing for three years.
(Scripting manual...that is pretty cool, gotta read line by line very carefully. It really is about merging Gcode and Lua together, basically the same thing as Mach3 did with Visual Basic)
(see Mach 4 customization manual...ya, where is that? ...and the appendices? lol! The dog must of ate Art and Brian's homework. I think the customization manual is just referring to the wx library that is C++ and GUI, hence wxLua or a lot f the screen calls (user interface object like programming...think point and click vs. cmd line entry; for example wx.wxMessageBox "enter your text here" and a dialog box appears which data that you want to see for step debugging variables or processes with fast response)
my hardware...Its small. haha! now that's funny :D I just have benchtop mill that I put together along with making the controller box from scratch. just a project like I think many of us do as hobbyists with a thirst for "How is that made?" "How do they do that?" ...and then, the potential in which you start doing what you love to do and your hobby starts to provide financial income and stability. Hat's off to those who have made it happen. I'm jealous.
-
nutz...MachGUI locks up when written into a button script. It compiles and runs fine in mcLUA and I am able to initiate movement and stop movement on tne tool setter but the GUI locks up when the motion is complete. any ideas?
Even tried this loop. Compiles and works in mcLua, works in button script but GUI just doesn't like it. Even adjusted PLC rate to 100....
while mc.mcSignalGetState (hSig) ~= 1 do
mc.mcCntlSetLastError (inst, "Approaching tool setter")
if mc.mcSignalGetState (hSig) == 1 then
break
end
end
-
Can functions be defined in the PLC scripts and arguments be passed back to them from button scripts? or do I need to build a module? But I would just be asking if I can use it in the PLC...
-
1). Yes
2). you can also use a module.
3). the module can also be used in the PLC
Another option is to put your func's in the load screen, and your calls in the PLC.
If you have a lot of funcs, it might just be easier to put it in a module to reduce clutter.
Scott
-
Thanx for answering! I appreciate it...load screen, plc...but what about the signal script? Is the signal script only created to handle external IO events by passing them to/from the load screen? I put a signal reference table into the plc and the signal script didn't like that at all....it started crying :o) So I put the signal reference table back into the load screen and the signal script did not give a nil error. Just curious, that's all. I think the plc's job is to monitor internal signals and functions calls (am I close?). Btw, I have been through the toolbox like 1000 times and it is really starting to click. Thanx for sharing and educating all of us!
--josh
-
poppa bear and YaNvNo and secret helper plus the other boys have done a shed load of good stuff, what I think is good they don't always give answers just good pointers to the answer.