Messages

1

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: August 09, 2019, 09:59:52 AM »

I downloaded the latest dev version of the Mach 4 and installed and it all seems to work a lot better - there are no spurious movements of the z-axis. The THC is now working fine - fantastic.

There are a couple of other issues with the software  - it doesn't seem to remember any of my settings (in the plasma screen) between sessions - I have to manually enter them each time - not a big deal - I guess this could be due to it being a dev version.

Sometimes the program stops after a pierce saying the a the OB motor took to long to move - 4 seconds (I'm para-phrasing here - I do not have the exact error message)... seems to happen after about 20 or so profiles in a single file. Agh - lots a messing about trying to reset/re-start the program and trying not to lose position.

Mostly all good though... thanks for your help.

2

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: July 29, 2019, 08:11:38 AM »

Ah ha... great - thanks.

3

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: July 29, 2019, 03:59:27 AM »

Hi Chaoticone

I have been responding to this thread with the title ...build 4225... on closer inspection I have build 4162 - which is still the latest version available on the download page. You say in your post that I should get the latest 'dev' build - is that version 4225 or is this an erroneous number in the original post?

I will try downloading and installing the latest version on the website again - to see if a fresh install will help.

The download page doesn't seem to offer dev version downloads - is there a way I can get the latest dev version?

Thanks

4

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: July 27, 2019, 04:27:29 PM »

Thanks Chaoticone

I understand it a bit better now - although I am slightly worried that it could be my UC400ETH motion controller's support of OBA that could be the problem.

I will try your recommendations on Monday morning when I am back in the shop and report back on how I get on.

Thanks again

5

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: July 27, 2019, 05:23:22 AM »

Then go back to x=0 y=0

Not sure where the instruction is to do this?


Using the OB1(6) motor is what is recommended in the Plasma Confiuration document included in the 4225 build document folder.

6

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: July 27, 2019, 02:52:39 AM »

Hi Craig,

Not sure why you would say that moving from X0 Y100 to X0 Y200 is cutting the same line - maybe I'm going daft.

My intension with the plasma is to have enough THC so that I can move across a sheet of steel at fairly slow feed and the THC will keep up - I think that is probably what the majority of what THC is needed for - certainly in our shop. Often a sheet doesn't sit level on the table - some times 10mm side to side - I am fairly confident that the response time will be quick enough. If and when I have the need to cut thinner steel at a high feed rate I may need to re-assess - probably go to a smaller nozzle, lower amps and feed at the same rate.

The Mach4 Plasma module is a Lua script - does this mean that it is totally independent of the motion control board - my intuition tells me that all of the THC control is done with in the software module - each time there is a signal from the PROMA to move the torch up or down, the software issues an instruction to the out-of-band OB(6) motor - the software then issues a command to the motion controller to move the z-axis Z(2) - as far as the motion contoller is concerned there is no difference between an OB(6) move and a Z(2) move...the only difference is in the software and its recording of the z-axis position.

Hmmm... at this point I'm not really sure what is the point of OB(6) - why not just move the Z(2) motor - something is not right with my understanding!!

I am trying to understand the above issues so that I can narrow down the culprit for the erratic z-axis behaviour. Is it the software? Is it the motion controller? Or is it the interaction between the two?

My current understanding is that the Mach4 plasma module is independent of the motion controller and if it is responsive enough - fantastic!

Teak

7

Mach4 General Discussion / Re: Mach4 build 4225 - Plasma feature instability

« on: July 26, 2019, 10:44:33 AM »

Hi jamie325i

I am having similar problems to the ones that you describe...so I thought I would add them into the mix...

I am using MACH4 build 4225 (Plasma) with a UC400ETH motion controller... I am using a PROMA 150 for THC. I am trying operate using the Thc Mode == Digital.

The test file I am using looks like this...

F500
G0 G90 G54
G0 X0 Y0.000
M3
G1 X0 Y100
M5
M3
G1 X0 Y200
M5
G0 Z10
M30

When I run the program using the above file it runs fine when using Thc == Manual (effectively not using THC), and then when I run it using Thc == Digital it seems to be working fine until it gets to the second M3 command - at this point things get a bit random - sometimes it plunges into the steel, and sometimes it raises the torch above the "Max find distance" - the torch is moving up but the DRO is reporting that it is moving down.

Sometimes it seems like the program is getting conflicted between the OB1(6) motor and the Z(2) motor.

I seem to be fairly close to getting this going but it just isn't quite working yet...

I have be trying to get this going for some time now, so any help would be very much appreciated.

FYI...
I was getting concerned about the safety of my torch so I created a simple Arc OK signal emulator using an Arduino - it enables me to test the system without the torch or the PROMA connected. If anyone wants more info on this just ask. Hasn't helped me solve the problem

Thanks

Teak

8

Mach4 General Discussion / Re: Mach4 MQTT Client

« on: January 16, 2019, 04:41:41 AM »

Hi Dusty91...Sorry for the delay in getting to this...

I did think that trying to trigger a process from and incoming MQTT could cause a threading problem i.e - the message arrives on a thread that does not have access to the main UI thread. So the message actually arrives - but it is difficult to 'see' it. Your approach of using the 'last_error' could be a way around this problem - and you seem to have got it working...I haven't tried it yet - when I get to it, I will try your approach.

Have you been looking at MQTT and Node-Red before you read this post or did you try all this once had read the post? I would be interested in hearing what you are doing with it - and whether you are already integrating MACH4 with you workflows? My principle idea is to integrate my cutting bench with an indexing machine - so the whole process can run all day using some kind of hopper system - is anyone doing this already do you know?

9

Mach4 General Discussion / Re: Mach4 MQTT Client

« on: January 08, 2019, 05:19:27 AM »

I haven't done anything since my last post... I could not get Mach4 to respond to an incoming message.

I notice in one of Newfangled promotional videos they talk about using MQTT with Mach4 - so maybe it is possible - maybe they have it working (in both directions)... Who knows!...they don't seem to pay much attention to this forum!

10

Mach4 General Discussion / Re: Mach4 MQTT Client

« on: January 01, 2019, 02:47:42 AM »

Hi Seb
I decided to follow the initial instructions you posted...

I got the library loaded and the errors fixed in the library that were not compatible with the current version of Mach 4... and I got Mach 4 to post a massage the MQTT server (I attached a routine to a button for testing). This worked fine - but I could not get Mach 4 to respond to an incoming message - did you manage to get this to work?

This is the code I added to the screen load routine...

Code: [Select]

function mqttCallback(
topic,    -- string
message)  -- string

wx.wxMessageBox("mqttCallback");

--mc.mcCntlLoadGcodeFile(inst, "C:\\temp\\AliLive6.nc")

--mc.mcCntlSetLastError(inst, "Topic: " .. topic .. ", message: '" .. message .. "'");
mc.mcCntlSetLastError(inst, "message - test");
end

function SendMessage(msg)
--wx.wxMessageBox("mqttCallback");

    mc.mcCntlSetLastError(inst, msg);
    mqtt_client:publish("mach4", msg)
end

function MQTT_Connect()
    --mqtt_client = mqtt.client.create("192.168.0.55", nil, mqttCallback)
mqtt_client = mqtt.client.create("192.168.0.3", nil, mqttCallback)
    mqtt_client:connect("mach4")
    mqtt_client:publish("mach4", "online")
    mqtt_client:subscribe({"mach4/set"})

mqtt.Utility.set_debug(true)
end

MQTT_Connect()
I also added this to the screen load routine...

Code: [Select]

--socket module
package.loaded.socket = nil
socket = require "socket"

--MQTT module
package.loaded.MqttModul = nil
mqtt = require "mqtt_library_mod"
and I added this to the beginning of the PLC script...

Code: [Select]

mqtt_client:handler()
Alas I have not been able to get Mach4 to respond to a message from my Node-Red server. I would be really cool if I could post a gcode file name to Mach4 and tell it 'go'...

BTW...this is my first attempt to do anything with Mach4 - so its quite possible that I have made some simple mistakes. Also - I am trying to do this with the demo version, since this kind of thing is the reason I would upgrade to Mach4 - I want to see if I could get it working first - it maybe the reason its not working!!