Hello Guest it is March 28, 2024, 08:41:19 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - simpson36

61
"If I use the physical Jog Increment Switch to control the increment, the Mach 4 display shows the correct setting and the "Jogging Inputs" controlled by the physical switches increment accordingly but the "Jogging" Mach display buttons increment according to the previous setting controlled by the Mach4 <Cycle Jog Inc> button.   Undecided Bummer  Anyone have any ideas "

My joystick uses only Jog functions and not MPG functions, so there is probably no parallel between our interfaces. My challenges were in keeping the environment separated between the screen jogging buttons and the joystick. For example the joystick would stop jogging movement if it was centered (not calling for movement) and this would also shut off the button jogging. The joystick changes the jog rate, so it was always left at zero, which is appropriate for the stick, but then the jog buttons would not work. And so on, and so on . . .

MPG is, at least in part, a separate environment, so there is less 'racing'.

Speculation on your issues;  The on-screen Jog increment button and DRO seem to be reporting the current system setting, however, a single jog increment setting would logically be either a separate, undocumented variable, or it sets each axis to the same jog increment. Each axis can have its own setting, so there is going to be a disconnect between the single button and the potential multiple rates. For example, if all axis are not at the same setting, and the on-screen single button/DRO can only display one setting, which axis is it reporting?

As far as I know, there is no function to set ALL axis at once, so you might try setting ALL axis one at a time to the same inc, including your unused axis B and C. Theoretically, this would resolve any confusion in the reading of the current inc by the system 'action' Toggle Inc (or whatever it is called).

Whatever the behavior is, it would likely also apply to jog rate, or any other 'one button, multiple settings' condition.

The odd enable/disable behavior is probably being caused by errors in the original PLC code provided by Newfangled Solutions.

Since I am not using the MPG functions, this is about all the help I can offer.

Good luck with your project and thanks for sharing!

62
Tim,

two questions, please;

1) What is a 'race condition'

2) Did you coordinate the MPG actions with the existing jog buttons? i.e. Do the screen jog buttons still function or does the user choose one or the other?

I have, or had, a completed interfacing a joystick jogging setup to MACH4 and it had not occurred to me to make sure it would coexist with the existing jog buttons. Seemed like it would be a simple matter to attend to . . . but ultimately required pretty much a complete rewrite of the joystick part of the code (which is in the PLC).

My device also has three rotary encoders (which is essentially the same interface as an MPG assuming quadrature output) but they are not for jogging and therefor do not interact with the internal jogging functions. For jogging, at least in my case, you must share the same resources with the existing system and that presented a very large challenge.


63
Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: May 27, 2015, 05:32:13 AM »
mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G1 X-10 Y-10 F450")

this does not work properly in a button its the wrong code for button

I don't understand your fixation with a button. I did not say the code would work in a button and the OP was reporting a bug, not asking for button code.

To execute a couple of lines of G-code from a button, a simple solution is this:

local inst = mc.mcGetInstance();
local rc;
rc = mc.mcCntlMdiExecute(inst, "G1 X10 Y10 F450\nG1 X-5 Y-5 F450")



"Lets use this topic to post any bugs we find in Mach 4. Lets keep this topic clean and to the point."


This thread is for bug reports and perhaps confirmation of reported bugs and perhaps even work around for reported bugs, but  I think this conversation has gone far off topic for this thread, so I'm done with it.

Have a nice day.

Unsubscribing . . .

64
Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: May 26, 2015, 08:06:11 PM »
that don't work well in a button if you read back it has been tried if you read the link it says what happens with each type of gcode execute or what ever 
also the only difference is you put in a F word to what I had all ready posted if you don't have a F word it uses the default speed

I really don't understand what you are saying here, but if you read carefully, you might notice that F is not the only thing different. The reason for the F is that the codes are now G1 instead of G0.

As far as making a proper macro to put in a button or anywhere else. I also already covered that.

I think you are accustomed to having finished code plopped in your lap, but I do not have time for that. I just point people in the right direction and for all but the complete newbee, that is usually enough. I think the fellow having the problem is plenty clever enough to take it from here.


65
Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: May 26, 2015, 04:44:16 PM »

Slightly better work around:


mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G1 X-10 Y-10 F450")

This will perform the rapids as expected.


Caveat: Running above code from the LUA editor,  if the motion is stopped with the on-screen stop button, no amount of coaxing would make it run again short of closing and reopening MACH4. Might work better saved as a proper macro. I stopped messing with it at the above work around.

66
Mach4 General Discussion / Re: MACH4 - Modbus
« on: May 26, 2015, 06:09:09 AM »
Unsubscribed . . . .

67
Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: May 26, 2015, 06:07:10 AM »

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")


Confirmed behavior in DRO. Not running motors yet so don't know if physical movement is also effected, but judging by how fast the line of code goes by, it is hard to imagine the motors are moving correctly.

Here is a Work Around:

mc.mcCntlGcodeExecute(inst, "G0 X10 Y10 F5\nG0 X-10 Y-10 F5")

Above line counts correctly in DRO

68
Mach4 General Discussion / Re: MACH4 - Modbus
« on: May 25, 2015, 11:57:40 AM »
Bit packing does work in Mach4

see the modbus tutorial/example in the tool box, it uses bitpacking to/from the screenset.

From my previous post ; "Mach4 unpacking seems reliable and fast and I will be using that feature."


MACH3 was the question, but that has been resolved (for my application).



69
Mach4 General Discussion / Re: MACH4 - Modbus
« on: May 25, 2015, 08:30:30 AM »
I did not say it is broken.  I asked a question . . over week ago . . which was not answered . . . as usual.

In fact I said is *seems* to be working.

In any case, having received no response, I created a solution that renders the whole question moot. Done deal. Movin' on.

70
Mach4 General Discussion / Re: Mach 4 Bug Reports
« 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.