Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: BR549 on December 03, 2014, 12:34:56 AM
-
Question for ya, Have you every started a new screen from scratch ??? I cannot get half teh things to work EVEN if I copy things like a button setup from a known working screenset.
What is the secret handshake ??? I cannot even get the enable button or cycle start or Feedhold buttons to work correctly.
Has something changed ??
(;-) TP
-
Thinking of probing have you given any thought to Probe calibration ? Can it be done in Mach4 so it accounts for tip offset from center ? (Tip NOT on centerline of spindle)
Just a thought, (;-) TP
-
if you do a lot of changes some computers require a lot of restarts of programs for stuff to stick, this one does not need that but my other one does
-
I cannot get teh Cycle Start , Feedhold,Stop to work correctly.
When you cycle start a program then feed hold you cannot restart by hitting cycle start again. The Gocde jumps to the end of the program and the buttons go DIM and that is it. You have to disable/reenable Mach4 to get it back.
I THINK that when you start from scratch you are missing HUGE amounts of scripting that the other screensets already have and you don't.
Strange bird this one is, (;-) TP
-
you need to add the scripts plc etc
-
Craig I do not know IF you have used the Haas IP probing system lately but it is a VERY nice package. Here is a Video. I have a LOT of those things in Mach3.
This will make you hit your Fanuc with a BIG hammer.
https://www.youtube.com/watch?v=lj8_9YHL5nc
HIYA Daniel, YEP I just checked and all that is Missing. (;-) There is a LOT of scripting to do on some STD buttons as well. LIKE THAT is gonna happen here. (;-)
(;-) TP
-
just do what second development team member suggested work out what order you wont all the button in work out what script goes with what button write it down or use note pad ++ it is better than note pad.
cut and past each type of script in under there type with what button they go with that will give your order for the scripts to be put in under there types
I am not going to be doing all the screen from scratch I wont but when I do the screen set that's for me I will be. I think doing it like I suggest will be the easiest way of doing it
one screen set I need just needs tool hight probing and a output on off and a move to for laser zero.
the other ones for my laser what just needs stuff removed from the standard screen.
-
just do what second development team member suggested
thats the "Squared" development team!! hahahahahaa >:D
Frick
-
Question for ya, Have you every started a new screen from scratch ??? I cannot get half teh things to work EVEN if I copy things like a button setup from a known working screenset.
What is the secret handshake ??? I cannot even get the enable button or cycle start or Feedhold buttons to work correctly.
Has something changed ??
(;-) TP
When you copy the buttons, are the associated scripts being copied? Doesn't sound like it.
-
Gerry I did not copy buttons(could NOT figure out HOW to copy from screenset to screenset) I created everything from scratch. I did HAVEgo back into working buttons on a working screenset and write down all the options that seemed to make it work AFTER I could not figure out WHY the buttons did not work correctly. But as I found out there is a bit of scripting needed behind the VISUAL screens that make some of them work as well.
EVEN then I am missing something somewhere because they still do not work correctly. Take the simple Cycle Start button. I STILL Have not gotten it to work correctly. As I found out there is SCripting in the PLC and Screen SCript that ALSO is needed to support the button call.
I am still working on it,Where is Klaus when you need him, (;-) TP
-
Craig, sorry I mixed you up with someone else.
JUST pickin on ya , (;-) TP
-
IF you want a bird's eye view of all the associated Code in a screenset do as Craig suggested and goto the screen XML and view . It has ALL of the screen code layed out for you to see. AND it is in screen order.
Next will be to get brave and get you a pair of sissors and a bottle of glue and get to cutting and pasting. That IS next on the list as I cannot figure out a way in the screen editor to move MAJOR things around.
(;-) TP
-
that be madman secretary
I am going to try and do the 2 codes I wont today
-
does anyone now the code to zero an axis after its moved to a position cant find any code for doing it
-
I think this may be what your looking for Daniell.
mc.mcAxisSetPos(inst, 0, 0.000)
-
VP ??? I cannot even get a screen button to work right ;D
Now for those Mcodes and param calls . THAT is the cats meow IT seems that there are 2 var sets associated withe G65#vars. Var_A and #1. The Var_A populates the #1 so the macro Parm call use it only querries the Var_A side and does NOT effect the #1. At least it seems that way here. I can't test with G65 here so it is just a guess as it does not show up in the Var monitor.
Does anyone know how many ways you can blow up a ScreenXML (;-) and still counting. Interresting those XML thingys
(;-) TP
-
Well I can move a control group AND it shows the new location in the TREE, BUT it will NOT display in the editor OR in Mach4. Restart Mach4 as well still no show.
(;-) TP
-
deep breaths
-
thanks gents I must be missing something cant get the axis`s to zero out.
this is what I have so far.
This works
--Laser Zero
--Get the instance of the controller
local inst= mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F500");--run some g-code
--Get the out5 handle
local out5= mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT5);
--Output TOGGLE
local outstate = mc.mcSignalGetState(out5);
if (outstate == 1) then
mc.mcSignalSetState(out5, false);
else
mc.mcSignalSetState(out5, true);
end
-
Daniel I do not see any code to zero the axis . Am I missing something
-
yer should of put in what I have tried
below works with out mc.mcAxisSetPos(inst, 0, 0.000) or mc.mcMotorSetHomePos(inst,0,0); -- inst, 0= X axis , 0 = set to home anything else is counts per unit
if I add one or the other of the above codes it stops the output turning off and the axis`s don't go to zero.
I put them in after gcode execute
--Laser Zero
--Get the instance of the controller
local inst= mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F500");--run some g-code
--Get the out5 handle
local out5= mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT5);
--Output TOGGLE
local outstate = mc.mcSignalGetState(out5);
if (outstate == 1) then
mc.mcSignalSetState(out5, false);
else
mc.mcSignalSetState(out5, true);
end
-
It worked here zeroed out the XY after the Gcode move
mc.mcAxisSetPos(inst, 0, 0.000)
mc.mcAxisSetPos(inst, 1, 0.000)
-
did you try it like this did it turn your output 5 on
--Laser Zero
--Get the instance of the controller
local inst= mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F500");--run some g-code
mc.mcAxisSetPos(inst, 0, 0.000);
mc.mcAxisSetPos(inst, 1, 0.000);
--Get the out5 handle
local out5= mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT5);
--Output TOGGLE
local outstate = mc.mcSignalGetState(out5);
if (outstate == 1) then
mc.mcSignalSetState(out5, false);
else
mc.mcSignalSetState(out5, true);
end
-
Have you setup output5 in config?
-
I cannot set up output 5 in the DEMO. BUT I did setup output3 and ran this code and it turned ON the output3.
--Laser Zero
--Get the instance of the controller
local inst= mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F50");--run some g-code
mc.mcAxisSetPos(inst, 0, 0.000);
mc.mcAxisSetPos(inst, 1, 0.000);
--Get the out3 handle
local out3= mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT3);
--Output TOGGLE
local outstate = mc.mcSignalGetState(out3);
if (outstate == 1) then
mc.mcSignalSetState(out3, false);
else
mc.mcSignalSetState(out3, true);
end
-
I am get output 5 on and off its just not zeroing x an y after move
-
Now the real kicker is IF I load the code and run it once it runs ok. IF I then run it a 2nd time it runs the Gcode twice in a row(0 -10/0, 0-20/0, CRASH) . IF I run it the third time it locks up mach4.
Probably a SIM() problem, (;-) TP
-
(;-) Its not doing ? what?
(;-) TP
-
I will try in virtualmotion
-
See if this bit works as expected. If it does, you can then build on it. I would work on one bit at the time.
local inst = mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F50");--run some g-code
wx.wxMilliSleep(10);
mcState = mc.mcCntlGetState(inst);
while (mcState ~= mc.MC_STATE_IDLE) do
mcState = mc.mcCntlGetState(inst);
wx.wxMilliSleep(10);
end
mc.mcAxisSetPos(inst, 0, 0.000)
mc.mcAxisSetPos(inst, 1, 0.000)
mc.mcAxisSetPos(inst, 2, 0.000)
-
this is what I have ended up with so far what's commented out is because it crashes M4
-laser zero
local inst = mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F500");--run some g-code
wx.wxMilliSleep(18); --it need to be set to this
mcState = mc.mcCntlGetState(inst);
--while (mcState ~= mc.MC_STATE_IDLE) do
--mcState = mc.mcCntlGetState(inst);
--wx.wxMilliSleep(30);
--end
mc.mcAxisSetPos(inst, 0, 0.000)
mc.mcAxisSetPos(inst, 1, 0.000)
--wx.wxMilliSleep (20)
so it looks like this so far to get it to work I have to home all first
-laser zero
local inst = mc.mcGetInstance();
mc.mcCntlGcodeExecute(inst, "G1 X10 Y10 F500");--run some g-code
wx.wxMilliSleep(18);--it needed to be set to this
mcState = mc.mcCntlGetState(inst);
mc.mcAxisSetPos(inst, 0, 0.000)
mc.mcAxisSetPos(inst, 1, 0.000)
-
SO does this mean that me still have the same problem in Mach4 as we had with Mach3 macros. The macros will NOT stay in sync as to Gcode and Lua AND order of execution AND we end up with a race condition. I thought we were going to fix that this time ???
(;-) TP
-
SO does this mean that me still have the same problem in Mach4 as we had with Mach3 macros. The macros will NOT stay in sync as to Gcode and Lua AND order of execution AND we end up with a race condition. I thought we were going to fix that this time ???
(;-) TP
This is probably the secret that makes Mach4 faster - the first thing I discovered using the laser is that S codes, some M codes and macro's will execute before the end of the preceding line of Gcode. Delays within the macro's resolved the issue but defeated the object by slowing everything down. It's still early days yet and I am sure there will be a suitable solution.
Tweakie.
-
I think I remember seeing a SWITCH to change that mode to SYNC.
(;-)TP
-
Are you running this in your PLC script section?
if so, your while loop MAY be waiting/running longer than the
PLC script scan and hanging it up, and crashing it...
You could do it as a state series if it is in the PLC script section.
***in the load screen section.
put a "RunOnce = 0;" global var
OR... you could set a global register (see the register plugin)
OR... you could set an unused #var
OR... you could set a screen User LED etc....
and use them in place of RunOnce in the code in the PLC section
***in the PLC script section
--MyMachEnabledSafetyVar can be if the enabled button is enabled for instance.
If RunOnce == 0 and MyMachEnabledSafetyVar == 1 then
DoGcode here.
end
If RunOnce == 0 and XaxisPos == 10 and YaxisPos == 10 then
Do your outputs or whatever...
RunOnce = 1;--so the runonce blocks dont run again.
end
-
its in a button script
poppabear at this stage I can understand zero of what you have put I would like to learn how to do the scripting with just pointers of what to do but that's not working if I had the manual I think I would be ok.
all off your help gents is very well come and thank you for the help
-
Here is a tip unless it is an Mcode MOVE your test script to a seperate Directory. Mach4 does funny things if run from the Profile/macro directory. Also Mach4 will PRERUN the macros in the Proflie/macro directory on startup.
I set up Mach4hobby/MACROS directory and run tests from there MUCH better stablility and NO weird stuff happening on testing.
Just a thought, (;-) TP
-
its not in macro folder in the button script.
for running the code its just a timing problem if I have a G code move plus output on off its ok when added zero x and y that's when it goes funny I just have to get the timing correct and it works fine.
there will be better ways of doing it but that's over my head at this time.
Its probable I could just do a call from a directory like you suggest, might try that any way
-
can some one help me I am trying to run a scripts from a folder named scripts.
I cant get the call right this is one thing I have tried I can get it to compile but not run I have it in a button script
package.path = "./?.lua;c:/Mach4Hobby/scripts/?.mcc;"
mc.mcScriptExecute(0, inst, "./?.lua;C:/Mach4Hobby/scripts/LaserZeroscript",0);
I have put this in screen load scripts its fine package.path = "./?.lua;c:/Mach4Hobby/scripts/?.mcc;"
is there something I am missing or can someone please give me an example of how to do it
-
got it working I think its showing up in log as, No script engine found for ./?.lua;C:/Mach4Hobby/scripts/LaserZeroscript
the script I am using is this
--Laser Zero call
local inst= mc.mcGetInstance();
local myScriptpath = "C:/Mach4/scripts";
package.path = "./?.lua;c:/Mach4Hobby/scripts/?.mcc;"
mc.mcScriptExecute( inst, "./?.lua;C:/Mach4Hobby/scripts/LaserZeroscript" ,0);
-
Hey, that script your using is for doing "Modules",
A few things:
If you want to use a module, you will need to create a module, (your script),
and if your using .mcc then you will need to compile the module.
your path will need to point to where your module is.
Your code that calls it, is also only partially complete.
you show getting the path, but your not calling/assigning the module to a variable.
See the lua website for how to make/use a module.
Scott
-
yea I thought I was doing it wrong I would probley be better off doing it as a macro
thanks scott
-
is there a move code like what was in M3
like this
Xmove = -73.3844 * 1/Xs 'Move distance adjusted for X-Scale factor
Code "G91 G0 X" &Xmove & "Y" &Ymove ' Makes an incremental move the distances that you set
-
local inst = 0; local rc = 0;
local Xmove = "X2";
local Ymove = "Y3";
rc = mc.mcCntlMdiExecute(inst, "G91 G0 X" .. Xmove .. " Y" .. Ymove);
-
In a M code script, one that will be run from a G code file, it is best to use
mc.mcCntlExecuteGcode() mc.mcCntlGcodeExecute() or mc.mcCntlExecuteGcodeWait() instead of mc.mcCntlMdiExecute(). MdiExecute will only run if the machine is in the idle state.
mc.mcCntlExecuteGcode() mc.mcCntlGcodeExecute() will not wait for the G code to complete. It is there so that button scripts can fire off code like the Goto Zero button uses. You don't really want to wait on G code in a button script as it will freeze the GUI until it completes. The act of executing the G code changes the machine state and you can use the state to lock out buttons to keep things from happening while the G code is running to completion. mc.mcCntlExecuteGcode() mc.mcCntlGcodeExecute() will call MdiExecute() if the machine is in the idles state. This is a good choice to use in button scripts.
mc.mcCntlExecuteGcodeWait() does as it implies. It will actually run G code while a file is running, so it is the best thing to use for M code scripts. Again, mc.mcCntlExecuteGcodeWait() will call MdiExecute() if the machine is in the idles state. Not so good for button scripts.
Steve
-
Steve == 'DA MAN!';
Scott
-
thank you very much