Messages

1611

Mach4 General Discussion / Re: Anyone know how to select tabs with an external input signal?

« on: March 21, 2020, 11:30:39 PM »

Hi,
excellent work!

As if often the case once you have devised a strategy for achieving a particular goal the actual coding
of it is trivial.

As a matter of programming style; directly using the 'scr.*********' table is not recommended. In most cases there is
an API or Mach variable that is 'exposed' for the purpose of customization...not withstanding the the scr.********* functions
can do the job. That is Smurph's recommendation anyway.

I myself am rather mystified by the syntax of the scr.********* table. I did find and post a list of the table entries:
https://www.machsupport.com/forum/index.php?topic=40051.msg271116#msg271116

Smurph has rather pointedly reminded us all to avoid many of the functions contained therein.

In this instance however you are using one of the basic and popular scr.********* functions and should be OK. The fact that
you have used the SigLib{} table speaks very well of the effort to learn Mach/Lua. Most newcomers settle for 'polling'
an input in the PLC script. The SigLib{} approach is FAR more elegant.

I too use Mach4Hobby but am not aware that MachIndustrial has any extra features related to this thread. Although I do
now recall that Mach4Industrial does make use of some of the scr.********* functions for a specific editing purpose....
although the details escape me. That's the good thing about Alzhiemer's...your always meeting some new!

Craig

1612

Mach4 General Discussion / Re: Configuring Mach4 with Hitachi WJ200 without Modbus

« on: March 21, 2020, 09:18:42 PM »

Hi,
at the current time there are six credible, and one not-credible (as opposed to incredible ) manufacturers of
Mach4 ready motion controllers.

PMDX, you are aware of, you might like to consider the PMDX-424, it has two ports developed and thus has double the IO
of the PMDX-412. PMDX do have threading but not realtime THC.

The UC series of controllers by CNCDrive, are good quality and stable however they have the least realtime supports and
misses on threading and realtime THC.

PoKeys 57CNC is good qualitiy and has a fairly complete set of realtime supports EXCLUDING realtime THC. The 57CNCdb25
is very very similar to what you have already, ie only one port.

The Hicon Integra by VitalSystems is good quality and has a full suite of realtime supports, some of which occur an extra
licence fee. In addition it can be activated (at additional cost) to handle closed loop analogue servos. Starts at $600USD
WITHOUT extra activations.

The ESS by Warp9 enjoys probably the most complete suite of realtime supports including threading, realtime THC and laser
vectoring/rastering. It is not a feedbback controller like the Hicon. Retails at $180, and requires a BoB or BoBs.
The previous model USS does not have a Mach4 plugin and is all but obsolete.

CSMIO/P and CSMIO/A are good quality but have a buggy Mach4 plugin, and contrary to their history have gone right
off the boil with their support. As they start at 600Euro I find it hard to recommemnd them despite their quality and undoubted
performance with Mach3. Their performance with Mach4 is just too patchy.

XHC is the only Chinese manufacturer claiming a Mach4 plugin but its so buggy I don't think anyone uses it. Avoid like the plague.

Craig

1613

Mach4 General Discussion / Re: MACH4 MACHINE Z WILL NOT ZERO ON HOMING

« on: March 21, 2020, 08:55:07 PM »

Hi,
the most likely reason your settings were overwritten is because you do not have a uniquely named profile AND screenset.

Most people have a uniquely named profile but just use the generic wx4.set screenset say. When they update to the latest
build a new wx4.set overwrites the existing. Therefore all your screen edits and tweaks are lost.

The correct procedure is to create a uniquely named copy of your favoured screenset and use that instead. Thereafter
all your screen edits and tweaks will be in the uniquely named file which WILL NOT be overwritten at update.

This procedure means you don't have to follow the renaming procedure Tom has outlined, just download and install
the latest build and nothing is lost in either your profile NOR your screenset.

Craig

1614

General Mach Discussion / Re: Homing Switches

« on: March 21, 2020, 08:02:08 PM »

Hi,
what is supposed to happen is that the Z axis moves in the nominated direction at the nominated homing speed UNTIL
the Z axis homing switch activates. The axis will stop. The axis will then move backwards UNTIL the Z axis switch
de-activates at which time the Z axis will stop again. At that point the machine coordinate of the Z axis is set to zero,
or the nominated Z axis homing offset, if any.

It sounds like your Z axis is moving in the correct direction and stopping as its meant to but not backing off the switch.

What kind of switch are you using?. It has been my observation that proximity switches are a poor choice because there
is vanishingly small distance between where the switch first activates and when moving backwards when it de-activates.
The amount of motion means that it is possible for flexure or vibration to cause repeated switch activations at which point
Mach gives up the ghost.

Snap action microswitches on the other hand have a well defined hysteresis and are less inclined to false trigering.
When an axis approaches a snap action home switch it activates the switch, stops and then backs off, often by as
much as 1/2mm which is visually apparent.

Craig

1615

Mach4 General Discussion / Re: Anyone know how to select tabs with an external input signal?

« on: March 21, 2020, 07:45:54 PM »

Hi,
I don't know if its possible, and certainly if it is I don't know how...at the moment.

I would guess that it is possible and probably not too difficult....once you have determined how.

All I can do at the moment is show what I have found and hope that I or others can furnish other ideas until a
solution is reached.

My investigations to date are in the pics attached. All of these screenshots were take while in screen edit mode and
also I undocked the ScreenTreeManager so that the screenshot contained all the relevant images.
The first screen shot is the MainTabs entry of the ScreenTree and noice the Properties, particularly the
DefaultTab and the CurrentTab, both 0.
The second screen shot is when the ProgramExtentsTab is displayed and note now that the MainTabs properties have
changed such that the DefaultTab is still 0 but the CurrentTab=1.
The third screen shot is when the MachineDiagnostiicsTab is displayed and note how the MainTabs properties
have changed again such that the DefaultTab is still 0 but the CurrentTab=2.
The last screenshot follows the same pattern, namely that the tab displayed is ProbingTab and the CurrentTab property
is  3.

I conclude that:
CurrentTab=0 means ProgramRunTab
CurrentTab=1 means ProgramExtentsTab
CurrentTab=2 means ProbingTab

and by extension:
CurrentTab=4 means OffsetsTab
CurrentTab=5 means SurfaceTab

So it looks to me that there is a variable OR a property 'CurrentTab' which if we could manipulate it programmatically
would allow you to achieve what you want.

So the research continues into indentifying the variable and/or property of 'CurrentTab'. If anyone knows anything about
it please chime in.

Craig

1616

Mach4 General Discussion / Re: 5 axis Pedant for Mach4 with Smootstepper ESS

« on: March 21, 2020, 06:42:36 PM »

Hi,
as far as the comms delay that Mike (mcardoso) refers to I have not noticed it in practice.

Like any MPG, if you spin the pulse generator wheel quickly and have a high or significant step increment set in
Mach4 it is entirely probable that you will exceed the axis speed and therefore end up with motion commands in the
buffer which will in turn result in after-run even once you stop spinning the wheel.

This used to happen to me when I had a 1mm movement increment per step set in Mach4. It was very easy for me to
end up with 20-50mm of movment stored up in the buffer......and no amount of panic on my part was going to change
that. I found the problem less pronounced when I set the maximum increment per step to 0.5mm per step, but my normal
setting is now 0.1mm per step. I can cause after-run if i really really try to spin the wheel as fast as I can but under normal
operating circumstances I don't end up with any after-run and can yet still jog plenty fast enough.

It has made me realise that after-run is not a fault, its what Mach is supposed to do....it did something stupid because that is
exactly what I asked it to do. Now that I have a realistic increment set the 'problem' has evaporated, I can jog as quickly
as I want or need and yet have the resolution for all but the most demanding of positioning ops.

As Mike pointed out the USB comms impose a delay between the pendant and Mach.

Follow this sequence of events:
1)The trajectory planner is otherwise unoccupied. The planner has been issuing a long string of zero movement PVT
(position velocity over time) commands to the motion controller in one millisecond intervals.
2)The motion controller has a buffer (180ms is the default buffer length in the ESS) full of zero movement commands
and so the machine is stationary.
3)The trajectory planner receives a step command from the VistaCNC plugin to execute a single increment step
on the selected axis.
4)The trajectory planner issues a string of PVT data slices to enact that movement, lets say 5 slices so that the move
takes 5ms.
5)180ms later (the buffering delay) the motion controller recieves the non-zero PVT data and the motion controller issues
the pulse streams for the axis motor to move as required.

Consider step 3) a little more closely. When the pendant MPG wheel is advanced one click the circuity within the pendant
assembles a frame of data to send to its plugin (here I am assuming a VistaCNC type plugin), then the frame of data is
communicated to the plugin, and thence to Mach. I would assume the plugin-to-Mach communication to be in the usec
range, likewise I would assume the hardware can compose the data frames in usecs, therefore the only (significant) delay
is the USB frame rate....around 8-12ms.

The total delay from the MPG pulse to the pulse be enacted by the motor is 190ms being the sum of the buffering delay
and the USB frame delay. Were it possible to eliminate the USB delay, the total delay from MPG to motor is 180ms.
Clearly the total delay is to all intents and purposes determined by the buffer delay NOT the USB delay.

Consider now the situation that you have a hardwired MPG to you BoB/ESS combination. When the MPG is rotated one click
the BoB/ESS hardware being essentially instantaneous composes a data frame to send to the ESS plugin which
in turn communicates to Mach. Machs trajectory planner then issues the same 5 non-zero PVT data slices, which is communicated
to the ESS via the same 180ms buffer.

The default controller rate for the ESS is 40Hz. Thus it will communicate frames of data back to it s plugin ( and thereby Mach)
with up to a 25ms delay.

The total delay from MPG pulse to motor pulse is 205ms, assuming the worst case timing of the MPG pulse realtive to
the ESS data frame timing, to 180ms, assuming the best case timing.

The total delay is still largely determined by the buffer delay.

Thus I disagree with Mikes contention that communication delays imposed by a USB (or other serial communication protocol)
place pendants at a disadvantage relative to hard wired MPG's, the total delay is determined nearly exclusively by the
buffering delay of the motion controller and is the same in both circumstances.

Craig

1617

Mach4 General Discussion / Re: 5 axis Pedant for Mach4 with Smootstepper ESS

« on: March 21, 2020, 03:03:35 PM »

Hi,
I have used a VistaCNC P1A for several years and and perfectly happy with it. It is four axis capable.
The P3 and P4 models from the same company are six axis capable.

I've never had an issue with the Estop running on a USB connection.

You may have noticed that Profibus, Ethercat and CanOpen all now run safety data over the network for industrial
machines.

Craig

1618

Mach4 General Discussion / Re: Configuring Mach4 with Hitachi WJ200 without Modbus

« on: March 21, 2020, 02:21:19 PM »

Hi,
to my knowledge BOTH the PMDX-411 and the ESS are good.

The reason that I suggested the ESS is because of the much expanded IO. The PID spindle control is
just the icing on the cake.

Craig

1619

Mach4 General Discussion / Re: Configuring Mach4 with Hitachi WJ200 without Modbus

« on: March 20, 2020, 07:39:49 PM »

Hi,
given that you have a UC100 as motion controller you have little flexibility because the IO is so scarce.

I will point out that if you used an ESS you would, if you employed all three ports have 51 input and outputs, quite a step up from 17 inputs and outputs in the UC100. In addition the ESS now offers PID spindle control so spindle speed within 1% is eminently feasible.

Craig

1620

Mach4 General Discussion / Re: Changing default state of toggle buttons

« on: March 20, 2020, 03:48:02 PM »

Hi,
got home, had something to eat, sat down.....and suddenly its the next day....I fell asleep!

As promised:
Close any Gcode that is running. Disable Mach4. Click the Operator Tab and select Edit Screen.
In the Screen Tree Manager double click the topmost item, it will be your profile name, in my example 'ESSMillwx4'.
Click the Events button in the Properties panel and viola there are the major scripts that form Mach, including the PLC
script. Click on the script and it will open in the Zero Brane editor.

Be sure to properly close the editor and save your edits, having one of these scripts open when it should in fact be closed,
ie after you have finished with it will crash Mach.

Craig