Messages

2461

Mach4 General Discussion / Re: Mach4 Huanyang GT series Modbus setup

« on: May 27, 2019, 09:47:43 AM »

Hi,
if you have a look at the code behind the DRO in the  screen editor I think you'll find its called 'TrueSpeedDRO'.

Mach displays the spindles true speed by timing the index pulses doing the required calculation and displaying the result.
If you do not have a index signal generator attached to the spindle the DRO will not display anything.

Craig

2462

Mach4 General Discussion / Re: Pin numbers for C76 multi-function board's port 1 output pin numbers.

« on: May 25, 2019, 08:39:56 PM »

Hi,
it seems to me that the C76 is giving you grief, and by the frequency of your posts and the time over which you have
made them makes me think you've bought a dog.

If I understand CNC4PC have tried to help but you still have not go it it to work?
Quite frankly, if even with manufacturers support, you cant get it to work then it is too complicated.
CNC4PC make a range of products and if the C76 doesn't work for you why don't you swap it for two or three C10's
which are really simple and only $23.00 each?

The UC300 is a good external controller......and is by necessity reasonably complicated, but here you have a breakout board
which is worse!!!!

Craig

2463

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 25, 2019, 08:28:42 PM »

Hi,
I wrote some code to put in the PLC script. It seems to work, that is to say that if you type in a new number
into the droGageBlockT and <enter> the PLC chunk will in very short order, within milliseconds, update the iRegs0/droRelay
register. As the PLC script runs multiple times per second, 20 times per second by default, the register should always reflect
the value of the DRO.

Code: [Select]

--Cause iRegs0/workZMax register to be updated by GageBlockDRO
local inst=mc.mcGetInstance()
local hreg=mc.mcRegGetHandle(inst,"iRegs0/droRelay")
local val = scr.GetProperty("droGageBlockT", "Value") 
mc.mcRegSetValue(hreg,tonumber(val))
--End of chunk
The question still remains...'will this short chunk maintain the updates when the Gcode Interpreter chunk is in control?'
Try it out and let us now.

Craig

2464

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 25, 2019, 07:42:05 PM »

Hi,
I experimented a little on my laptop along the lines of your proposal and I had a similar problem.
I haven't really sorted out why.

What I found was that just because I entered a new number into the DRO that did not necessarily translate  into the update
of the iRegs0 register that I was using as a relay.

I altered the code of the 'On Update' event script to copy the data from the DRO to the destination register. The data WOULD
be copied, I found, if I hit the <Set Z> or <Set Tool> button. I concluded therefore that the 'On Update' script runs
reliably ONLY AFTER one of the two buttons is pressed.

The only way I can see to overcome this problem is to put some code into the the PLC script that copies the data from the
DRO to the register. I am loathe to do so because of the software overhead that represents but there may not be much choice.

The second question remains, lets say we did bite the bullet and put code in the PLC script to keep the register updated,
or as I call it 'in lockstep' with the DRO.....does that code run during Gcode interpreter sessions.  It would really only make sense
that the PLC script should run irrespective of which chunk (GUI or Mach core) is in control. This is the true measure of my
ignorance of how Mach4 works, but the truth is I don't know whether that is the case or not.

In some respects while I endeavor to help others by contributing on the forum, I in fact have to learn about Mach and I do so
by others posing questions that I never thought to ask. Thus its contributing to the forum that aids my learning curve.

Craig

2465

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 25, 2019, 02:06:24 AM »

Hi,
well I tried my search scheme and it didn't work.

This is the macro I wrote:

Code: [Select]

function m190()
local inst=mc.mcGetInstance()
for  i=1,10000,1 do
local data=mc.mcCntlGetPoundVar(inst,i)
local match=math.abs(data-1.4142)
if (match<0.001)then
local poundVariable=tostring(i)
wx.wxMessageBox("PoundVariable is"..poundVariable)
end
end


end
if (mc.mcInEditor()==1)then
m190()
end

I entered 1.4142 into the GageBlock DRO but got no match. Just to test that my search macro was working I entered the same
number into the Z and Y DROs and the match was signaled.

I can only guess that the GageBlock DRO is not stored as a pound variable.

I think it high time I listened to wiser heads like smurph, Daz et al.

Craig

2466

Mach4 General Discussion / Re: Mach4 Homing Incredibly Slow Problem

« on: May 25, 2019, 01:54:24 AM »

Hi,

So if I understand correctly, I need to get 6 inductive proximity switches, and fit them onto my machine at each extent of travel - right?
Then I should wire them into 6 individual empty input terminals on my Hicon controller - e.g. P11/Input3,4,5,6,7,8.
Then configure the input signals (in Mach4) e.g....
P11/Input3 = Motor0--
P11/Input4 = Motor0++
P11/Input5 = Motor1--
P11/Input6 = Motor1++
P11/Input3 = Motor2--
P11/Input4 = Motor2++

.... and this will give Mach4 clearly defined limits on each axis, past which it must not travel the machine ?

Yes, that would be ideal.

I did not go as far, but as it transpired I should have. What I did is have three home switches each with their own input.
Then I had all six limit switches, ordinary snap action microswitches all in series as limits, all to one pin.

Guess what, I had a moment, the X axis went over limit and the machine stopped as its supposed to. I then hit the jogX-
button, of course the wrong bloody way!!!! and wrecked the switch. If I had six limit switches each with their own input
my programming would have prevented me from jogging in the wrong direction and breaking things.

I learned two lessons, individual limit switches are good and switches which don't get wrecked are likewise good.

Individual limit switch circuits are the norm in industrial practice and with good software and controllers like Mah4 and the
Hicon there is no reason for us not to do the same thing.

Craig

2467

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 25, 2019, 01:20:15 AM »

Hi,
I have gone and looked again through all the named registers in the Regfile Diagnostic tree and there is no such
 'droGageBlockT'.

It must therefore be a pound variable.
I have posted some lists of known pound variables and Enums and other uselful lists here:

https://www.machsupport.com/forum/index.php?topic=40051.0

But nowhere in the pound variable lists is there a listing for the GageHeightDRO.

There are two ways to proceed, one is to ask smurph or Daz or Chaticone or someone who may know.
The other is to do some detective work and maybe like Holmes deduce the answer. Are you up for a challenge?

My suggestion is  to deliberately write some unusual number into the DRO like 1.414213562, being the square root of 2,
(obviously!!!LOL) and then running a script to search through all the thousands of pound variables until we find one that
has that number stored in it. I am assuming that the number is unique....so there is the possibility of getting it wrong.
On the other hand if we do find a pound variable with this number in it then there is a good chance that we have deduced
which pound variable its is.

Does this sound feasible?

Craig

2468

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 25, 2019, 12:11:19 AM »

Hi,
there is  second issue going on.

Mach4 has two chunks of code, the GUI chunk and the Gcode interpreter chunk. Only one chunk can run at a time.
The data and code of one chunk is not available to the other. In the parlance......a variable in the GUI chunk
is 'out of scope' to the Gcode interpreter chunk and vice versa.

The variable  'droGageBlockT' is variable that is defined in the GUI chunk. When you run your macro from the Gcode editor
which is in the GUI chunk the variable  'droGageBlockT' is in scope. However when you run the macro the Gcode interpreter
is active and the GUI chunk and all its variables are out of scope.

That is the explanation as to why it will run from within the script editor but not when running as a macro.

Learning how and when each chunk runs in Mach is one of the steep learning curves of Mach.

In this case because you are using a .scr call it is by no means plain to me that .scr calls have return codes as do the .mc
API calls.

I would advocate that you should use a return code test to determine success or otherwise of an API call, it will in particular
catch those situations where you have inadvertently called a variable or function that is out of scope. Given that I'm not sure
that .scr calls even have return codes I cant recommend that technique.

What you/I/we need to do is find the register (if there is one) or more likely the pound variable that contains the current DRO
value and use that instead. Registers are the only means of transferring  data from one chunk to another. Registers and
pound variables are truly global whereas  'droGageBlockT' is 'global' ONLY within the GUI chunk.

Craig

2469

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 24, 2019, 11:49:42 PM »

Hi,
you have a few things going on there.

First lets deal with:
local hreg = mc.mcRegGetHandle(inst, string.format("droGageBlockT"))     

I don't know where you got this from but its wrong.
To get the handle of a register you must supply a string that has the path to the register. Even if there is a register
called 'droGageBlockT', and if there is I cant find it but its certainly not a correct path to it.

I have in my installation a register called:
workZMax
and it is in the instance register tree and this is how I would get the register handle for it:
local RegHandle=mc.mcRegGetHandle(inst,"iReg0/workZMax")

So to access a register you must specify both its name and path EXACTLY or the API will fail. The path to a register is
reminiscent of the path to a file on a Windows PC and  'droGageBlockT' is not such an example.
'core/ droGageBlockT' or 'ESS/'droGageBlockT' or 'iRegs0/ droGageBlockT' at least have the right format for the path string.

As I say....I could not find any mention of a register called  'droGageBlockT' anywhere in the Regfile Diagnostics tree and
am not surprised that you cant fing a handle for it.

Craig

2470

Mach4 General Discussion / Re: Read droGageBlockT

« on: May 24, 2019, 05:56:34 PM »

Hi,
what is the register?

How are you trying to read the DRO?

Craig