Messages

7291

General Mach Discussion / Re: Crosshairs and Home line

« on: December 23, 2016, 02:58:45 AM »

Hi Scandi1,
not sure I understand what you're asking but have a look on Config/ToolPath page and experiment
with the settings there. You may find some thing that suits.

Craig

7292

General Mach Discussion / Re: Can this be true, free Mach Turn CADD CAM/PP that works?

« on: December 23, 2016, 02:45:18 AM »

Hi DICKEYBIRD,
yes its for real. I used it for some months and it does a pretty good job.

I think this is Autodesks way of enticing potential customers to try their wares. Once you become accustomed to
their interface and way of doing things then you will want to try their other products as well. Having said that Fusion 360
is pretty damn good.

In the event I found the CAD part not so good. I think its meant to be easy and intuitive for newcomers and to be fair it is that.
Also the freehand drawing and 3D modelling is meant to encourage almost artistic creation and again to be fair it does that.
What I found frustrating is that flexibility/intuitive thing prevented me from setting the properties and behaviour that I wanted
for engineering parts and I went back to my regular CAD/CAM which while is very cussed to use given the level of setup and determination
required it can thereafter produce VERY good CAD and excellent toolpaths optimised for the job at hand.

Try Fusion 360, I think you will be impressed. You may not hang with it forever but the again you may....its good.

Craig

7293

General Mach Discussion / Re: Please help me remove the red lights!

« on: December 23, 2016, 02:19:09 AM »

Hi,
not sure I can help but I can try.

How are your switches wired? The pic shows them at the very end of the table so I guess you're combining limit
and home switches. Also shown it the pic looks like the head of the screw is what actually is detected. Are you able
to shift it?

Can you post a screen shot of the Config/Ports and Pins/Input Signals page.

What I'm going to suggest it that you shift the head of the screw an inch or so back within the table travel area. Really helps to
have a little to play with while your experimenting and learning. Then I would suggest disabling the limit switches and use it
as a home switch only. I suspect what's happening is that the machine is stopping because a limit switch is triggered. Try in the
first instance to get it working as home switch then try to incorporate it as a limit switch as well once you've got homing sorted.

Craig

7294

Mach4 General Discussion / Re: re-mapping motors and home switch inputs through lua script

« on: December 22, 2016, 11:33:51 PM »

Hi Cal,
I've been thinking about this all day. I think what we are considering here is the heart of how Mach4 works with a motion
controller.

I think axis slaving is done by the controller, at least I understand this is the case for the SmoothStepper. The SmoothStepper configuration
plugin registers and maps the axes and motors and informs Machs core with API calls like those above. I don't believe Warp9 the plugin developer
has left functions exposed that may be manipulated programmatically other than through the configuration dialogue.

One possibility that occurs to me is that it might be possible to configure Mach to run the master/slave setup. The Mach configurator Axis Mapping
tab seems to suggest it might be possible. Under that circumstance I imagine that Mach would produce two nominally identical position/velocity over
time commands which would be in the controller mapped to two different and independent motors that happen to be on each end of the gantry.
As we can communicate to Machs core via API commands it would be possible to temporarily break the 'indentical' streams so each motor could act
independently to square the gantry.

As it stands Mach issues one position/velocity command which the controller applies identically to two motors.

The only other solution would be to have two axes, say X and A configured indentically and modify your G code:

G1 X1.5 Y5  say would become
G1 X1.5 A1.5 Y5

Doable but time consuming. How it would work with arc moves or canned cycles makes my head hurt.

Discounting the G code manipulation I think the question to be posed to those who know Mach and perhaps controller plugins
best is 'Can Mach control its own assignment of master/slave or MUST it be done by the controller plugin?'

I've noted in the API that there are a number of commands that have C/C++ syntax but no LUA syntax, ie those commands can only be
used by plugins or modules in C/C++. The commands that we're thinking about which do have LUA syntax does not
necessarily mean that they could be used in a script to achieve anything useful.

Craig

7295

Mach4 General Discussion / Re: Mini ITX Motherboard for Mach4

« on: December 22, 2016, 10:55:55 PM »

Hi Bx3mE,
glad you've had some success. I am coming to the opinion and only restating what Jeff Birt wrote that Mach4 like Mach3 are not processor
hungry applications but they are time sensitive, you can't just stop midstream because of some other application, device or service.

The only time I've found the Atom to be wanting is when I run a software utility which processes G code files, for a 5Meg file it can take several
minutes whereas my laptop (Intel i7,2ghz, hardly a world beater) takes 15-30 sec to do the same job. As a straight machine controller I think
the Atom is going to give tons more service yet.

Craig

7296

Mach4 General Discussion / Re: re-mapping motors and home switch inputs through lua script

« on: December 22, 2016, 12:42:23 PM »

Hi Cal892,
I started experimenting after posting and have been thinking about it overnight. I'm now unsure that what looked like promising
instructions will be of use.

Even if you can couple/uncouple motors in Machs Core using them will the controller follow suit? If memory serves, when I set up the ESS
plugin it registered and mapped the axes which suggests that temporary rearrangements would have to be made there.

Craig

7297

Mach4 General Discussion / Re: Logging M4/ESS probe events

« on: December 22, 2016, 04:52:02 AM »

Hi DTG,
roger that. Last day of work tomorrow and the a few weeks rolling/grovelling/excessing in the hobby/obsession!

Need to get to the machine to get the live data. When I run the sim of course the probefile is perfect.

Best wishes of the season and may Santa bring you a set of 'you beaut' servos and drives...

Craig

7298

Mach4 General Discussion / Re: re-mapping motors and home switch inputs through lua script

« on: December 22, 2016, 04:36:48 AM »

Hi Cal892,
if I understand what you want to do is when you wish to reference your machine you wish to 'uncouple' two
motors, home them individually and then slave one back to the master when the gantry is square?

Would  mcAxisMapMotor and mcAxisUnmapMotor be of any use?

I was thinking the process might be:

1) home Xaxis with both motors coupled to one home switch on your nominal master rail
2) unmap the slave motor and jiggle it back and forward until the gantry is square with a secondary home switch
3) remap the slave to the master
4) issue mcAxisHomeComplete.

In the API all of those calls have LUA syntax and I imagine therefore could be used in a script.

Craig

7299

Mach4 General Discussion / Re: Logging M4/ESS probe events

« on: December 22, 2016, 04:11:52 AM »

Hi DTG,
as you know I've written a couple of macros, or should I say modified macros that came with M4 as examples, that open
and close the probefile. Additionally the close macro can detect and delete duplicate entries and 'massage' the raw data
into the form that the utility can use. Might add too, the exercise in LUA coding has left me VERY impressed with its flexibility
and power.

I have not been able to solve the issue with multiple records though. What I do have is a working fix for the data.

I would still like to find a reason for the multiple records, everything else in M4 has worked perfectly, once I at least understood
how.

'Looking under the hood' is a time honoured tradition for me to really understand something.

Craig

7300

Mach4 General Discussion / Logging M4/ESS probe events

« on: December 22, 2016, 02:52:38 AM »

Hi All,
I have an issue with a probefile and needs to get some 'tools' to solve it.

I use a software utility to probe a PCB blank on a set of mesh points, the board I'm working on at the moment has 210 probe
mesh points which are recorded in a file. The G-code probe job runs fine, the file is created and the data triplets recorded.
The problem it that the file contains more data triplets than probe cycles, sometimes as many as 220 after only 210 probe cycles.

Thought in first instance that I had a noisy probe circuit. I've used this setup with M3/PP for sometime without this behaviour.
Tried increasing debounce settings on ESS probe pin, no change. Fitted capacitor to the BOB pin with a time constant of 1ms, no change.
Have probed the output of the BOB with my scope and have yet to find any switch bounce. I can't categorically state that its not a hardware
issue but increasingly forced to believe the hardware is good..ergo the ESS/M4 combination is randomly recording two events instead of one.
When an extra unintended data triplet is recorded its a duplicate of the preceeding entry.

I have watched the ESS plugin diagnostics page like a hawk when a probe job is running but have yet to see a fault. There doesn't appear to
be any facility to log the diagnostic so I can only watch it in realtime, hardly conducive to finding a fault if there is one. Does anyone know if the
diagnostic can be logged either by a built in facility or maybe some code that would have to crafted to do so?.

Have had a look at the M4 log but have only a few guesses at what all the entries mean. Is there any documentation official or otherwise that might
allow me to make more sense of what I'm seeing?

What I'm hoping is that I can record a probe job run log and then either manually count the events in the log or 'strip' the logfile of irrelevant entries
to focus on the probe event/issue of data triplet record to the outgoing file stream.

Craig