Hello Guest it is April 27, 2024, 09:11:19 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 »
51
Mach4 General Discussion / Re: tool height probing
« on: June 30, 2015, 12:32:01 AM »
Does your hardware support G31?

52
Write a script using the 'AxisSetMachinePos' function. I believe that is the function that would apply to your requirement. I.e., setting a new offset for Xaxis. (This is just off the top of my head, look at mach4.api to find the right function for your application.) Hope this helps a little and points you in the right direction...

53
 Positivity is contagious.

54
I totally understand you are not arguing. I appreciate your time and response. This is how I learn. I mean, I was legitimately asking these questions. I really wanted to expand my knowledge with m4, especially in this scenario (MPG/jogging/resource conflict/timing/processing, etc). It is important to me to respect all views and alternatives. Sharing lessons learned and best practices is why I choose to be apart of this forum. It's the communication and topics like these that I am proud to apart of the m4 community. Thanx!

-josh

55
Mach4 General Discussion / Re: Custom DRO script
« on: June 25, 2015, 12:34:16 AM »
try this...

Operator -> Edit Screen -> insert new DRO -> label 'droXdrillOne', DRO code is blank, Editor = In Place, make any other personal formatting changes
                                   -> insert new DRO -> label 'droXdrillTwo', DRO code is blank, Editor = In Place, make any other personal formatting changes

Goto PLC script, try the following code. It's a start at least. mc.mcAxisGetMachinePos vs. mc.mcAxisGetPos = your preference of display

do
    local inst = mc.mcGetInstance()
    local Xpos = mc.mcAxisGetMachinePos (inst, 0)  

    local myOffset1 = ----enter your axis offset, drill 1----
    local myOffset2 = ----enter your axis offset, drill 2----

    local drillOneOffset = Xpos + myOffset1
    local drillTwoOffset = Xpos + myOffset2

    scr.SetProperty('droXdrillOne', 'Value', 'tostring(drillOneOffset))
    scr.SetProperty('droXdrillTwo', 'Value', 'tostring(drillTwoOffset))
end

There are many ways to accomplish what you would like to do. This is just one possible solution. Add, delete, modify, Play! :)


56
Mach4 General Discussion / Re: Custom DRO script
« on: June 24, 2015, 11:44:58 PM »
create newDRO, have PLC update this newDRO with a local variable that 1. get axis position, 2. apply your offset formula and 3. use a screen set property call to write that value to your newDRO.

same concept as using a DRO to display mm conversions from your current DRO inch display as ya-nvr-no demonstrated is his posts about screen sets. if it is not working like you want just let me know and i'll also work on it with you.

--josh

57
Mach4 Toolbox / Re: Simple button script to rapid to a know position.
« on: June 24, 2015, 11:24:00 PM »
yes, yes, and yes :o) There a hundreds of way's to this, tailor this, or implement whatever you want. True Daz, I would enable the button or execute the movement to position zero 'if axisIsHomed then...." execute gCode movement just to be safe else if the call was executed before all axes are referenced then the positioning might be off. Example, x axis is binding (with stepper motors) and DROs continue movement. When I stop movement and then Goto Zero before homing my axes, the positioning will be off. I know you know but just in case someone new might like an example. Senior and experienced operators know this and would not need such a conditional statement. But m4 is so easy and flexible, why not!

...it is a lot of screen changing for an MDI input? It is one click, enter block of instructions, press cycle start...oh it's sooo hard! haha, just kidding. You can create a button and label it say 'Offset 3' and you can execute movement to your offset position, or create offset registers and reference those registers in the button to goto that position, or create a DRO that accepts manual input and read that input as a string value variable (screen get property call) and execute gCode movement from there (I think that may be what you are asking...that's a good project, I'll work on it for a bit and let ya know...great idea :)

58
I really like using event flags (ie. if flag = some value then reset or reassign flag value; call some fancy function end <- in the PLC) and then defining global flag variables and associated function in the screen load up script therefore all that is needed is to set some action or button press to flag = 1 for example.

It is really interesting that you have observed greater latency with signals, whereas for example.... once a signal is sent/received the signal script will reference the signal table and execute the associated function.

Both processes will execute an action based on an event. It's really the samething in my mind. signal states = flag values...if 'true' then reset; execute else 'false' end.  I noticed the greatest latency when using functions in button scripts to adjust DROs. Then using the button to set a flag value in which the PLC catches and references a function in the screen load up script was still a little off but not as much. The best method was just to write the function in the PLC, so the PLC will only execute the function if the flag's value is true. I observed this with in->mm conversion DRO's. The best return is six ten thousands off exact value. Now, if you are in mm to begin with (config settings) it will be exact.

I mean as far as processing.. (this is my question)...everytime the PLC runs it tests only the conditional statement. If false then the PLC will skip to the end and continue. The PLC will not even go over the event function. Therefore, the only additional time required by the PLC is to evaluate one line...until, the condition is true. Correct?

So if timing is an issue shouldn't we just write our functions in the PLC? ...and then events in which time is not an issue, those functions can be defined and referenced from the screen load up script.

59
haha, thanx Dan! I just wanted to make sure I wasn't sacrificing safety or resources by using simple screen calls for a cosmetic make over....hey, we all have our dream girl! :)

60
imported the set into another computer. gotta unhide the dros in the screen tree manager and adjust in mach config-toolpath-top & bottom color to black....must be a personal *ini setting. I can just set it at startup in the next edit.

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