Hello Guest it is October 21, 2019, 09:21:43 AM

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 - smurph

221
Mach4 General Discussion / Re: Coordinate Rotation
« on: March 05, 2018, 09:50:41 PM »
Anytime you use mcCntlGcodeExecuteWait or mcCntlGcodeExecute, you are firing up an new interpreter (which hasn't any rotation applied to it).  So you will need to check for rotation in those macros and apply it to the G code that those functions will execute. 

-- SV_ROTATION_X                   2135 stores X value from G68
-- SV_ROTATION_Y                   2136 stores Y value from G68
-- SV_ROTATION                       2137 stores Z value from G68


local inst = mc.mcGetInstance()
local grp15 = mcCntlGetModalGroup(inst, 15) -- G68 and G69 are in modal group 15.
CodeLine2 = ""

if (grp15 == 68) then
CodeLine2 = 'G68 X#2135 Y#2136 R#2137\n'
end

CodeLine2 = CodeLine2 .. 'G00 Z' .. PierceHeight .. '\n'
CodeLine2 = CodeLine2 .. 'F' .. ProgramFeedrate
mc.mcCntlGcodeExecuteWait(inst, CodeLine2)

Steve

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

Steve

223
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

224
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

225
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

226
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

227
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

228
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

229
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

230
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