Messages

631

Mach4 General Discussion / Re: New Mach4 interface designer suite (Lua)

« on: March 05, 2018, 02:15:04 PM »

Another one (work in process), but you will get the idea.

Steve

632

Mach4 General Discussion / Re: New Mach4 interface designer suite (Lua)

« on: March 05, 2018, 02:08:20 PM »

Use the Mach4GUI.  People are making lots of really modern looking screens with it.  All done with background/button images and custom fonts.

Otherwise, you will need to suddenly become a programmer (not recommended). 

Steve

633

Mach4 General Discussion / Re: New Mach4 interface designer suite (Lua)

« on: March 04, 2018, 02:56:34 PM »

You can use whatever you want to develop a GUI with Mach 4 as long as it can interface with WINAPI style DLLs.  Mach4GUI.exe is just a GUI front end for the Mach4Core.dll.  I have a C# based GUI and a VB based GUI that I have played with.  wxMach.exe is another "static" GUI front end.  But beware that there is NO support from Mach for this type of thing.  OEMs tend to use this stuff and THEY support what they write.  Any and all scripting that is done in the GUI will also have to be implemented. 

Mach4GUI.exe is a BIG and complex project.  Duplicating its' functionality would not be an easy task for all but a well seasoned developer.  So is it possible?  Yes.  Is it feasible?  Only you can answer that.  I'm not sure what that crank software suite uses.  From reading about it, it looks to be just a UI modeling suit so that engineers can model up the UI so that real programmers can duplicate it.

LUA cannot interface to WINAPI style DLLs, so LUA is not a candidate for a complete GUI.  Now, one could write a C/C++ exe that hosts LUA and then go from there.  But there would need to be a lot of "glue" code. 

Steve

634

Mach4 General Discussion / Re: Finish Z Move before X or Y

« on: March 02, 2018, 02:54:57 PM »

This is exactly what is happening.  Constant Velocity (CV) is a misnomer.  It really should be called Velocity Blending.  And CV is highly dependent on the motor tuning.  A lower accel/decel value will cause more "rounding" in the blended moves.  Higher values stay closer to the actual path.  Obviously, you want to set your accel/decel values as high as your hardware will allow to get the best results.  For servo systems, I usually tick the accel value to the point where the drive faults out and then back it down 10% for a little bit of margin.  For steppers, that point is where you start losing steps.  If you play around with it, you may get your system to the point where it really won't make much difference.

I also find it useful to use CV during roughing and constant stop on the last finish pass.  Tailoring the tool path in the CAM system can accomplish this.  If your machine is acceleration challenged, then you might have to modify the post processor to include G09 (one shot exact stop) for the lone Z feed move.  I like that better than using a G04 dwell.  But to each their own. 

e.g.

G09 G01 Z-20. F2031.24 (here is where it happens)

Steve

635

Mach4 General Discussion / Re: Possible Feed Rate Bug?

« on: March 02, 2018, 02:33:41 PM »

I'm sorry. I didn't intend to offend anyone...

I didn't know what relates to feedrate fluctuation. What I saw was fluctuating feedrate but with smooth motion.

No offense taken.  I just want everyone to understand how this works.  We don't write the motion plugins and there needs to be a distinction between Mach's responsibilities and the responsibilities of the motion plugins in these matters.  The end user needs to realize it may be a problem with the plugin and seek help from the plugin vendor.  And I will work with the plugin vendor to correct the issue if they need help.

Not writing the motion plugins is both a blessing and a curse, if you will.  It is a blessing because it allows for competition between motion devices.  Each device fitting a niche that the others don't.  If we wrote the motion plugin, there would likely be only one motion device and it would probably be overkill for a lot of our users.  It is a curse because people assume that we control everything and then don't understand the roles that that Mach and the motions plugins play.  It is definitely a "team effort".  Mach will not do much without a motion plugin and the motion plugin won't do squat without Mach.

So I spend a lot of time pointing out these distinctions.  It is necessary.  It is not a finger pointing game, mind you.  But rather information to help guide a person to a resolution if they are having a problem. 

Steve

636

Mach4 General Discussion / Re: Possible Feed Rate Bug?

« on: March 01, 2018, 05:17:11 PM »

I think Mach4 has some issue presenting correct feedrate...

Be careful with blanket statements like that.  Mach only "presents" what it is fed back to it from the motion controller.  What are you changing?  You are changing ESS parameters in the ESS plugin, not changing anything in Mach.  Maybe ESS has some issue with feed rate reporting at frequencies higher than 160.  But it isn't Mach.  It could depend on the type of G code file you are running as well.  If you are running a 3D file with CV and the ESS is reporting back to Mach faster that it was at the lower frequencies, then you will see more feed rate deviation.  So is it a > 160 ESS problem or just a symptom of faster reporting?  I don't know.  But again, it isn't Mach.

Another issue is motor capability.  Mach will cap the velocity of a move to the slowest motor in the move's capability.  So if X is able to move at 300 inches a minute and Y is only able to move at 200 inches per minute, then Y will limit X to 200 inches a minute in an XY move, even if you set F300. 

Remember, just because you specify F60 in the G code, that doesn't mean the machine is going to actually do that.  CV and motor velocity capping can and will change it if the conditions warrant. 

if the feed rate fluctuations are a symptom of the type of G code being run and you wish to see a more consistent feed rate, you may want to implement some sort of averaging scheme.  One could do that in the PLC script.  But if CV is causing the feed rate fluctuations, you would consistently see a lower feed rate average than what you specified with F in the G code.  Think of F as a maximum feed rate allowed when using CV. 

Steve

637

Mach4 General Discussion / Re: Probe1, Probe2,Probe3, PMDX411

« on: February 25, 2018, 08:01:11 PM »

As Steve S. said in another post, there could be a hardware solution to this problem.  The G31.x stuff is purely a software convenience that is found nowhere else in the CNC world.  Usually, M codes are used to "turn on" a specific probe before G31 is called.  The M codes would typically control outputs that in turn control relays that enable the probe signal path to the desired probe.  I have multiple probes (tool setter and spindle probe) on my machine and that is how it is handled because it used to run Mach 3 and before that it had a YASNAC control on it.  It works well, so I have never "upgraded" to G31.X. 

Steve

638

Mach4 General Discussion / Re: scr.getProperty – Macro Parameters – Registers

« on: February 25, 2018, 07:37:09 PM »

I read the feature requests.  And I sometimes respond to them.  But most of the time I can better use the time that I would take posing to actually work on something.  If the support people want to comment on them, I guess they could.  But there is one recent one in there, for example, about UNICODE characters.  I don't respond to some of them because I really don't want to get into a discussion of the nitty gritty of why it is the way it is.  But rest assured, I read each and every one of them.  And then I make it look like they were my ideas!  LOL  Seriously though, I like the fact that the feature request thread is more like a list than a discussion.

I did read your post about it.  I had already had plans to do exactly that because of another project in the works.  In fact, I had already been working on it a bit  But I really had no idea when I would get time to finish it.  So I didn't mention it because the next question would have been "When can we have it?" and I would not know.  And I won't mention what the other project is for that same reason.  But just know it will be really cool and it will hopefully help a lot of people out. 

Steve

639

Mach4 General Discussion / Re: scr.getProperty – Macro Parameters – Registers

« on: February 25, 2018, 06:33:09 PM »

The latest builds of Mach can provide this functionality.  There is a new DLL in the Modules directory called screenipc.dll.  

scr = require("screenipc)
scr.scIpcInit('127.0.0.1")

Then all of the screen API functions are available to the macros.  Put that line (and also making sure that cpath and path will see the Modules directory) in a file by itself in the Macros driectory.  I think Brett had an example for loading modules for all macros (loadmodules.mcs) or something.  

The screen API is already available in the PLC script, since the PLC script is part of the screen.  Looks like you were using the PLC script just for stuffing values from the screen into registers...  I saw scr.GetProperty() in use.  

But anyway, you can now use scr.GetProperty() and friends directly in the macros.  

Steve

640

Mach4 General Discussion / Re: Possible Feed Rate Bug?

« on: February 25, 2018, 03:30:24 PM »

smurph: Bug is present on completely stock install of MACH using simulator motion controller with zero third party plugins installed. I would see that as best case scenario so MACH should feedback exactly what was it was told.

The Sim plugin is not a motion controller.  It is not real-time and it uses Windows timers to make it tick.  A 10% variance in timing is quite the norm for Windows.  It doesn't feed back exactly what it is told.  It feeds back the feed rate that it is able to produce.  The Sim plugin is used as an example for people who wish to write motion controller plugins.  Therefore, it is written to use the API in a manner that real motion control plugins would use.  I could make it feed back exactly what it was fed from Mach, but that would not be a very good example.  

So the moral to this story is that Sim is not perfect.  Windows is the "bug".  It relies entirely on Windows and every Windows machine will have different timings depending on what components make it up.  A real motion controller will provide better feed rate feedback.  Also, it is common to have some feed rate variance when CV is in use.  You will see the feed rate drop on corners.  How much depends on the acceleration capabilities of the motors.  But a straight line should report a feed rate VERY close to the desired feed rate.  But do keep in mind that not all motion controllers will report the current feed rate at a frequency that appears instant.  Some could only report at 250 millisecond intervals, for example.  Also, the screen DROs will only update at the screen refresh frequency (stock is 50ms) no matter how often the feed rate is updated.  

Steve