Hello Guest it is November 15, 2019, 04:45:14 AM

Author Topic: DRO behavior  (Read 1237 times)

0 Members and 1 Guest are viewing this topic.

DRO behavior
« on: November 09, 2017, 01:29:30 PM »

If a DRO who's DRO code is set to CurrentJogIncr. has a valid number (read, one of the 10 jog increments defined) entered through the keyboard the 'core/inst' register entries for JogIncX through JogIncC are updated with the new value and when incremental jogging is requested the axis moves the correct amount.  Same thing occurs when using the 'Incremental Jog Step' button. 

It appears that some event is triggered when the value changes.

If however you change the value programmaticaly, e.g. scr.SetProperty('droJogInc',"Value",tostring(SetInc)) , the event is not fired.  Shouldn't any change to the 'Value' call the update event/action?
Is there a way to force/call that event/action?

Additionally, it you write to the registers, new values:

        mc.mcJogSetInc(mInst, mc.X_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.Y_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.Z_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.A_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.B_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.C_AXIS, SetInc) -- set inc for axis

they are ignored on further incremental jog requests.  Is it not correct to read the register for the jog increment each time an incremental move is made?

And why is there no mcJogCycleIncrement() api available?

TIA

RT
Re: DRO behavior
« Reply #1 on: November 09, 2017, 03:49:29 PM »
Hi RT,
just as a guess the jog increment is read from the profile. You would need to cause the new value of an increment
be written to the profile and then have Mach read the profile before the updated data is correctly loaded.

Craig
My wife left with my best friend...
     and I miss him!
Re: DRO behavior
« Reply #2 on: November 09, 2017, 04:03:09 PM »
Hi,
here's a quote from smurph, it was regarding programmatic axis mapping but sound like indentical behaviour
to jog increments:
Quote
The config dialog just reads the profile's Machine.ini file and displays those values.  NOT values that may have been modified at run time by scripts and API calls.  When you hit OK (or Apply) on the config dialog, the profile's Machine.ini will be updated with the values in the dialog (changed or not) and then when the dialog closes, the core will re-read the profile's Machine.ini.  Thus "undoing" any run time modifications.  Even if you hit CANCEL in the config dialog, the run time modification will be undone, as the core will ALWAYS re-read the profile's Machine.ini file.  The core does not know if you pressed OK, or CANCEL on the configuration dialog. 

If you modify the values at run time and then shutdown Mach (without entering the config dialog), the modified values WILL be written to the profile's Machine.ini at shutdown and then next time you start Mach, those values will be used. 

So if you ever want to see the run time modifications in the config dialog, you must also modify the Machine.ini file with the mcProfileWrite*() functions (with the appropriate keys and values) and call mcProfileFlush() afterwards to write them to the disk BEFORE entering the config dialog.

Craig
My wife left with my best friend...
     and I miss him!
Re: DRO behavior
« Reply #3 on: November 09, 2017, 04:05:26 PM »
Hi,
and the complete thread from which it came

http://www.machsupport.com/forum/index.php/topic,33866.0.html

Craig
My wife left with my best friend...
     and I miss him!
Re: DRO behavior
« Reply #4 on: November 09, 2017, 05:40:26 PM »
Afternoon Craig,

Thanks once again for taking a stab at these problems.

The profile does not contain a current increment, rather it has a current 'JogIncSet' which is the index into the 10 settings and I have changed the value programmaticaly:  mc.mcProfileWriteInt(mInst,"Preferences","JogIncSet",CurInc) that along with flushing and reloading the profile but it has not made any difference in the outcome.  I have a sneaking suspicion that in this case they have chosen to not re-read the registers or the current indexed value.  I could be wrong, wouldn't be the first or last time, but my tests seem to show otherwise.

And of course it does not address the other parts of the questions asked.

RT

Offline Chaoticone

*
  • *
  •  5,628 5,628
  • Precision Chaos
    • View Profile
Re: DRO behavior
« Reply #5 on: November 09, 2017, 05:42:16 PM »
Not sure what all you are doing but keep in mind, jogging with on screen buttons, jogging for script and jogging from say a pendent are 3 separate things. Changing a setting in one will not set it in the other unless you handle the switch in the script............. or they all run the same functions.

Maybe not the answer to your question but this should work in place of your script below.

for i = 0, 5, 1 do
   mc.mcJogSetInc(mInst, i, SetInc) -- set inc for axis
end
;D If you could see the things I have in my head, you would be laughing too. ;D

My guard dog is not what you need to worry about!
Re: DRO behavior
« Reply #6 on: November 09, 2017, 05:55:43 PM »
Hi,
on the Configure/Mach/General  page there are the settings for the different increments, where do they come from
if not the profile?

Craig
My wife left with my best friend...
     and I miss him!

Offline Chaoticone

*
  • *
  •  5,628 5,628
  • Precision Chaos
    • View Profile
Re: DRO behavior
« Reply #7 on: November 09, 2017, 06:08:03 PM »
Depends on how your doing the jog. The on screen buttons use them. Jogging through script doesn't have to.
;D If you could see the things I have in my head, you would be laughing too. ;D

My guard dog is not what you need to worry about!
Re: DRO behavior
« Reply #8 on: November 09, 2017, 07:50:37 PM »
I am not at this stage trying to jog anything.  I am trying to get the jog increment changed programatically so that later I can use a xBox to change it and have the xBox and the keyboard have the same increments all the time.  Every time I change the increment I play a wav file that tells me what increment I have selected.  Since my Lua panel code was unsuccessful I just added a button to refine the tests.

Attached are two pics, one of the dro with dro code set to Current Jog Incr. and the button with code below.  If you open the register diagnostic window and pin it like the second photo you can see the registers change.

Here is the button script


Code: [Select]
        local NewInc=0
        local i=0
        local mInst=mc.mcGetInstance()
        local CurInc = mc.mcProfileGetInt(mInst,"Preferences","JogIncSet",0) --Get the previously saved setting in profile to hold our current inc number
        local SetInc = mc.mcProfileGetDouble(mInst,"Preferences","JogInc",0.00) -- fetch our inc value from the profile JogInc + 2 say = [Preferences][JogInc2]
        --check to see if the JogInc exists
        for i = 1 , 10 ,1 do
          if SetInc == mc.mcProfileGetDouble(mInst,"Preferences","JogInc"..tostring(i),0.00)then
            mc.mcCntlSetLastError(mInst,"Matched "..tostring(SetInc).." - "..tostring(i))
            NewInc=i
          end
        end
        --did we find a match
        if NewInc==0 then
          mc.mcCntlSetLastError(mInst,"current setting does not match")
        end
        --choose the next increment
        if NewInc==10 then
          NewInc=1
        else
          NewInc=NewInc+1
        end
        CurInc=NewInc
        SetInc = mc.mcProfileGetDouble(mInst,"Preferences","JogInc"..tostring(CurInc),0.00)
        --this is where I assumed it would be the same as typing a new value in but it isn't
        scr.SetProperty('droJogInc',"Value",tostring(SetInc))  --set the dro to the distance to jog

       --save the profile updated information
        mc.mcProfileWriteInt(mInst,"Preferences","JogIncSet",CurInc) --set our profile to new CurInc         
        mc.mcProfileWriteDouble(mInst,"Preferences","JogInc",SetInc) --set our profile to new SetInc
        --[[assumed the above would change the registers but it doesn't so do it, this was commented out to test
            whether the button code changed the registers but it didn't while a manual entry of a jog increment key press did
            same as Scott's for i,0,5 example
       --]]
        mc.mcJogSetInc(mInst, mc.X_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.Y_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.Z_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.A_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.B_AXIS, SetInc) -- set inc for axis
        mc.mcJogSetInc(mInst, mc.C_AXIS, SetInc) -- set inc for axis     

        mc.mcProfileFlush(mInst)
        mc.mcProfileReload(mInst)
    --    local s=tostring(CurInc)
    --    mc.mcCntlSetLastError(mInst,s)
do a couple of jog increment presses,  then jog, and then do a couple of button presses and a couple of jogs and you will see that the even though the
values have been written to the prfile and the registers changed the jog is still what ist was set to before the button presses

All this really proves is that Programatically entering a new value in a jog dro does not have the same effect as entering a value manually.  And shows that writing to the profile and registers does not have the same effect as using the Jog cycle increment key.

Or did I miss something here?

RT
Re: DRO behavior
« Reply #9 on: November 10, 2017, 08:09:05 PM »
Hi RT,

Quote
All this really proves is that Programatically entering a new value in a jog dro does not have the same effect as entering a value manually.  And shows that writing to the profile and registers does not have the same effect as using the Jog cycle increment key.
Correct.

When Mach4 starts all its setup values must be read from the profile. There is no other place for data to be stored. Even registers have to be written to profile and therefore
the hard drive prior to shut down and then repopulated from the profile (ie hard drive) when Mach4 restarts another session.

If you look on the edit screen page at the jog buttons and the increment cycle button they have Actions not scripts. That is to say that internal to Mach there is code to enact
the behavior we wish. The problem is that we can't see the code and do not therefore know exactly how it does that. As you've proved JogX+ say does not use the register
value for the increment. My guess is that the register value is used at start up to initialize a pound variable and that pound variable is used by Mach.

Therefore changing the register or profile value may not necessarily immediately change Machs jog behavior.

May I suggest an experiment....choose some unusual jog increment, say 0.3, and using you code update the profile and/or registers. Try some jogs to confirm that despite
your having programmed a specific but unusual increment that it has not in fact been enacted by Mach...ie the perceived fault. Now shut Mach down and then restart.
Do the registers get repopulated with your choice? Does Mach correctly use the jog increment you nominated?

If it does and I suspect it will it proves that Mach is not actually faulty but its behavior is different to what you might have expected. I had exactly the same issue
in the thread I linked earlier. It appeared to me that I had found a bug but was not in fact faulty at all. Until I understood the sequence of operations I could not
use Machs features because they seem unreliable. Once I understood the sequence of events the features are deterministic and perfectly reliable.

This may prove/disprove how Mach operates but does not immediately solve your problem. To get the behavior you wish you may have to write your own event scripts
in place of the actions, or find a means to causing Mach to re-read the registers so that its internal variables are current, or identify those internal variables and manipulate
them directly.

Craig
My wife left with my best friend...
     and I miss him!