Author Topic: Mach 4 Bug Reports  (Read 343988 times)

0 Members and 1 Guest are viewing this topic.

Offline cncman172

  • Active Member
  • Posts: 178
    • View Profile
Re: Mach 4 Bug Reports
« Reply #350 on: May 24, 2015, 07:41:44 AM »
Simpson36,

I have both but have been working with the USB Pokey for my pendant.

Russ

Offline simpson36

  • Active Member
  • Posts: 1,374
    • View Profile
Re: Mach 4 Bug Reports
« Reply #351 on: May 24, 2015, 08:54:48 PM »
Simpson36,

I have both but have been working with the USB Pokey for my pendant.

Russ


Russ, thank you for the response.

I have the USB version of the PoKeys, but have never used it.  I planned to purchase the Ethernet version, but the functionality that it provides is already available to my application thru the Ethernet interfaced Arduino DUE processor that I use.

The Arduino DUE continues to be able to handle the ever increasing loads I am putting on it, but in the event it stalls, I have the new Rasberry processor in a box waiting to be pressed into service if needed.

The USB version of anything has two ways of interfacing with a PC. One is as a native USB device and the other far more common (unfortunately) method is via a single chip 'converter', the most popular of which is made by FTDI, to emulate an old serial COM port.

ALL COM emulators require drivers and It is reasonable to assume that the driver would have FIFO buffers to emulate any modern UART chip.

Note that I do not know  if this is the case or not with any particular device, but I do think it is a reasonable assumption, which if true, would result in the same behavior that I described in an earlier post. Characters are trapped in the buffer and released when MACH4  starts and accesses the buffer without first flushing the buffer.   Again, that is pure speculation, but with a basis.

I can add that MACH4 is derelict in initializing a number of processes, not just serial plug-ins.  The screen does not initialize properly in that any custom buttons are in a completely random condition on start-up regardless of the initial state of the control.

It has been suggested by another post that code would need to be added to the PLC to properly initialize MACH4, but I strongly disagree with that premise.  I have had the last 9 or 10 questions go unanswered on this forum and developer participation seems to have pretty much ended. This seems to me to be heading for a repeat of the MACH3 norm of never ending unfixed and unacknowledged issues.

If that turns out to be the case, and extensive programming is needed to make MACH4 do what it should do out-of-the-box, I would be more inclined to follow the lead of others and abandon MACH4 in favor of the Kflop or Unix solutions.
« Last Edit: May 24, 2015, 08:56:40 PM by simpson36 »

Offline ger21

  • Global Moderator
  • *
  • Posts: 6,127
    • View Profile
    • The CNC Woodworker
Re: Mach 4 Bug Reports
« Reply #352 on: May 24, 2015, 09:07:43 PM »
I agree that developer participation is sorely needed here.
It often appears that the developers have no idea of what gets posted here.
Brian does answer questions on the Yahoo group, but almost all Mach4 activity is here.

The developers aren't doing anything to inspire confidence in those hoping for the Mach4 that we've been waiting years for.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

Offline dude1

  • Active Member
  • Posts: 1,251
    • View Profile
Re: Mach 4 Bug Reports
« Reply #353 on: May 24, 2015, 09:34:16 PM »
if you look at the plc and other bits they have a on off for screen buttons, axis`s but not jog it probley needs a on/off for jogging to not work when the machine is not enabled if its not the screen jog being used that is disabled a different way

Offline dude1

  • Active Member
  • Posts: 1,251
    • View Profile
Re: Mach 4 Bug Reports
« Reply #354 on: May 24, 2015, 09:35:30 PM »
I agree that developer participation is sorely needed here.
It often appears that the developers have no idea of what gets posted here.
Brian does answer questions on the Yahoo group, but almost all Mach4 activity is here.

The developers aren't doing anything to inspire confidence in those hoping for the Mach4 that we've been waiting years for.

your a mod ger have a word with them, poppabear cant do it all

Offline ger21

  • Global Moderator
  • *
  • Posts: 6,127
    • View Profile
    • The CNC Woodworker
Re: Mach 4 Bug Reports
« Reply #355 on: May 24, 2015, 10:22:37 PM »
if you look at the plc and other bits they have a on off for screen buttons, axis`s but not jog it probley needs a on/off for jogging to not work when the machine is not enabled if its not the screen jog being used that is disabled a different way

No,this should not be in user accessible code. When it's disabled, it should be disabled, an it should be done where it canct be changed.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

Offline dude1

  • Active Member
  • Posts: 1,251
    • View Profile
Re: Mach 4 Bug Reports
« Reply #356 on: May 24, 2015, 11:40:10 PM »
its this bit here from screen load whats x,y,z,a
function AxisEnable()
    local inst = mc.mcGetInstance();
    local ena
    ena = IsAxisEnabled(0);
    scr.SetProperty('xPos', 'Enabled', ena);
    scr.SetProperty('xNeg', 'Enabled', ena);
    scr.SetProperty('btnZeroX', 'Enabled', tostring(ena));
    scr.SetProperty('btnZeroX2', 'Enabled', tostring(ena));
    scr.SetProperty('btnRefX', 'Enabled', tostring(ena));

and there a chunk in the PLC that stop screen buttons working under certain states yes that should be locked away but you would have to get someone to put them in if you had more than x, y, z, a and different screen buttons other wise there would have to be a lot of basic screens to cover all requirements.

I may be wrong.

changing the scripts whats there now makes them work when you don't wont them to or not work when needed I played with them and had to reinstall so they should have a note with them don't touch

it all works as it is with no run away axis`s when you have not got any external control over screen buttons add in external control as people have found and bad things happen, that's why I think there needs to be stuff added to stop it happening

Offline simpson36

  • Active Member
  • Posts: 1,374
    • View Profile
Re: Mach 4 Bug Reports
« Reply #357 on: May 25, 2015, 07:43:43 AM »

The PLC has aces to the jogging functions, but it cannot effect anything until it is started. From the description of the behavior of the 'runaway jog' issue, it happens very early in the startup sequence.

If the solution was as simple as adding a few lines to the PLC, one would think they would have done that by now, given the exposure this bug brings with it.

   

Offline dude1

  • Active Member
  • Posts: 1,251
    • View Profile
Re: Mach 4 Bug Reports
« Reply #358 on: May 25, 2015, 03:35:28 PM »
have you had a look what happens to screen button`s when not enabled to enabled there is a differences non screen buttons have a different behavior. how can it be pre put in everyone will set up external buttons a different way

jogging with the same keys as M3 does not have this problem I am using M4 every day at the moment useing different keys bad things happen

Offline Dan13

  • Active Member
  • Posts: 1,244
    • View Profile
    • DY Engineering
Re: Mach 4 Bug Reports
« Reply #359 on: May 26, 2015, 01:40:03 AM »
Looks like a bug:

Trying to execute Gcode from LUA. This script works fine:

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\n")


However, with the below function, the numbers in the DROs do not continuously update, but only when the final destination is reached.

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G0 X10 Y10\n")


When trying to execute two line of Gcode, like below, the DROs again don't update continously, but only when the final point is reached.

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\n")
mc.mcCntlGcodeExecute(inst, "G0 X5 Y5\n")


Dan