Hello Guest it is April 29, 2024, 10:28:58 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 - Fledermaus

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 »
91
striplar

Yes, I definitely saw it after a config change, though it took me a while to link the two, by which time I had decided to eliminate it as it struck me as pretty hazardous.. I was by then working on a way of using a set of direct access buttons, so combined the two objectives.

Allan

92

striplar

Quote
I originally did this without scripts but found there's a bug that occasionally moves 1" instead of 1mm!!!

Maybe I've lost you somewhere, but how did you avoid your problem with unexpectedly changing units?

Allan

93

Quote
when they experiment, they simply find that it doesn't work how they might reasonably expect.

Agreed, but I tend to accept Mach4 for what it is, powerful yet amazingly good value, and use the flexible scripting to make it work as I would wish. It can be a challenge but to me that is part of the fun.

Allan

94
Steve

Thanks for the insights given in the two videos. I now see that mcJogSetInc() and mcJogSetRate(), which I took out of my code thinking they seemed to serve no obvious purpose, do fulfil a potential need. Another hitherto invisible gem is scr.DoFunctionName(), which obviates the (rare) temptation to have a hidden button operated by (e.g.) scr.ButtonUp() which itself can have side effects such as transfer of focus, just to make a script take an action.

I think I'll take another look at my own jogging code to see if I might make any changes  some 6 months after it was written. A key objective, though, was to avoid any surprise switches from metric to Imperial units, so I will continue to disregard any internal increment values.

I do appreciate your giving the time to clarify some of the considerable mystique we users find in the inner workings of Mach4.

Allan

95
striplar

As I said, I never managed to resolve the inconsistencies so I think you will have to hope Steve has some  idea.

Have you come across the mcErrorCheck.lua module in Mach4's modules directory? This lists the possible rc codes and can be handy in your scripts. For example you could use something like this:?

Code: [Select]
if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, "Jogging error:" .. ec[rc])
end

This would append the offending error message to the text of your choice.  so may make it easier for you to resolve any issues that arise.

To use the above, you must link in the mcErrorCheck.lua  module using a require statement, the typical code being:

Code: [Select]
----------AW Load error check module ---------------
local inst = mc.mcGetInstance()
local profile = mc.mcProfileGetName(inst)
local path = mc.mcCntlGetMachDir(inst)
package.path = path .. "\\Modules\\?.lua;" .. path .. "\\Profiles\\" ..  profile .. "\\Modules\\?.lua;"
package.loaded.mcErrorCheck = nil
ec = require "mcErrorCheck"

This may already exist in the screen load script: if not you can safely add it.

Allan

96
striplar

If you display the RegFile diagnostics, you will find entries for core/inst/JogIncX etc for the 6 axes. These are all set to the same value, as you would expect. You might like to see how these compare with the varables you are reading and writing. There are also 6 registers for the jog rates, but I have only seen these set to 0.

I initially used the values from these12  registers, but eventually abandoned that idea because their values did not always reflect what I had previously set. Sorry I have forgotTen the details.

As I said earlier, I ultimately abandoned trying to fathom out what Mach was doing and worked independently. Since then I have had no issues whatsoever with jogging. I do use the Config list as the basis from which my button names and jog increments are taken, so these can easily be changed without further coding.

It would be fascinating to see what the core actually does: I would especially like to see the logic behind Mach's state machine.

Allan

97
Steve

I have contacted CS Labs numerous times advising them of the Waiting on Set Still ... issue. But to date and despite several updates of their plugin, the problem remains. Mach4 logs indicate absolutely normal behaviour upto the wait but motion simply does not begin, so clearly this one is a controller issue.. When it works, it works admirably, but when it stalls in this way ...

I will continue to provide them with feedback on each new release, but their development  seems rather sluggish. This is a shame as in essence they have a very good and well priced range of products.

Allan

98

To answer my own question, I placed the following code into the PLC script to give a continuously updated view of the probing registers for the Z axis:

Code: [Select]
  -- AW Temporary test display of machine and user probe position
  local zAbs = mc.mcCntlGetPoundVar(inst, mc.SV_PROBE_POS_Z)
  local zMach = mc.mcCntlGetPoundVar(inst,mc.SV_PROBE_MACH_POS_Z)
  scr.SetProperty("droTestAbs", "Value", tostring(zAbs))
  scr.SetProperty("droTestMach", "Value", tostring(zMach))


The registers were updated following a probing cycle, whether or not the probe struck, and their values agreed with those of the normal screen DROs at the same instant.

Register values remained constant until the next probing cycle: they were not affected by writing to the Z screen DRO to change the fixture offset. In this regard, the IP/A behaves as I would expect and its behaviour is the same as that of the SIM.

Michal

I cannot reproduce what you experience, which strikes me as incorrect. What version of Mach4 and the CSMIO plugin are you using? I would be inclined to back up your Mach4 folder and then to try an update.

Allan

99
Michal

I was a bit confused by your last post. To be clear, I would have assumed that #5063 and #5073 are updated following a probe strike and I would not have expected them to change at other times. But that is just my assumption. Are you saying that if your fixture offset is changed, these registers are altered to match? I suppose that could make sense too.

Allan

100
Michal

Sorry to take a while but I had a job to finish this afternoon.

I don't ordinarily directly display the values you mention, so rigged up a test screen to probe Z and stop when the probe was hit. I displayed the following results:

  #5063   mc.SV_PROBE_POS_Z
  #5073   mc.SV_PROBE_MACH_POS_Z

These agreed  (within my display resolution of 0.01mm) with Mach4's normal user and machine coordinate DROs. In other words, the two register values differed by the Z axis fixture offset, as one might expect. I saw no strange scaling factors at work. I have imperial screws but work in metric with a counts per unit of 3937.

My system uses the IP/A  rather than the IP/S with plugin 3.014 and Mach4 3804.

The problem that I have is that probing randomly hangs Waiting on Set Still ... That can be very frustrating when it happens but apart from that probing works very well

Craig

The regs with Mach in the name are machine coordinates, the others are user (work) coordinates.

Allan

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