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

151
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

152
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

153
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

154
Mach4 General Discussion / Re: Possible Feed Rate Bug?
« on: February 25, 2018, 03:02:53 AM »
The current feed rate is supplied as feedback from the motion controller.  So maybe there is a timing issue? 

Steve

155
Mach4 General Discussion / Re: Tool Life Management
« on: January 29, 2018, 08:37:30 PM »
But yeah, Craig nailed it!  LOL

156
Mach4 General Discussion / Re: Tool Life Management
« on: January 29, 2018, 08:36:41 PM »
Check your PMs.  :)

157
Mach4 General Discussion / Re: Tool Life Management
« on: January 29, 2018, 08:25:56 PM »
You had to go there, didn't you?  LOL!!!

Steve


158
Mach4 General Discussion / Re: Is Mach4 really Hobby Material?
« on: January 26, 2018, 07:55:09 PM »
Reinhard,

On the Galil, you would use the TM command.  TM is set to 1000 (approx 1ms) by default.  That is the time base that everything uses.  Increasing or decreasing the value of TM would be tantamount to feed rate override.  The challenge then becomes to tie the value of TM to an analog input.  This can be done in Galil DMC programming where a thread is dedicated to watching the analog and adjusting the values of TM (and possibly the PID values to if using servos.  As I said, the Galil is a complex controller.  They have good documentation, but it still takes years to master every facet.  Meaning it is up to you to read the documentation and implement what you want to do.  You will NEVER see a reference to feed rate override in their manuals.  They give you the tools, you just have to figure out how to use them.  However, if you buy a Galil, they do offer great support.  They have good application engineers to help you get what you want out of the controller.  

In order to run a Galil with Mach, you have to know how to run a Galil by itself first.  I run a Galil on one of my machines.  I consider it a viable hobby level controller IF you are willing to learn about it and IF you can/want to afford it.  Budgets being what they are, everybody has their own levels to which they draw a line.  Buying a Galil on eBay is not for the crowd that knows nothing about them.  There are so many different models and a LOT of them on eBay were custom designs made for a particular purpose.  And Galil offers no support for used controllers.  So you better know exactly what you want to pull the trigger on an eBay Galil.

Multiple pass threading starts each thread pass on the index pulse on the encoder or the pulse per rev input.    The infeed amount is already there.  All that remains is synchronizing the Z feed rate with the actual spindle speed.  Z always moves from the start point to the end point and never needs to be re-planned.  It is NEVER as complicated as people make it.  It is actually quite simple to produce a high quality thread with just a spindle pulse and a calculated trajectory.  But it does take a real-time environment to implement the control loop.  

There are real-time extensions for Windows.  The problem is that all of them cost big bucks.  It would more than double the price of Mach.  There are two types for Windows, mainly; Hypervisor and HAL.  A Hypervisor is running a RTOS on the hardware that then partitions a CPU core (or more) to runs Windows in a VM.  The HAL method uses a custom Windows HAL.  The HAL type turns Windows into a true RTOS and can be implemented with a single core processor.  Of the two, I prefer the HAL type.  Interval Zero https://www.intervalzero.com/ is one that I like.  In fact, they have a product called KingStar that implements a software EtherCAT controller.  They are developing a plugin which is nearing completion.  They demonstrated it running a machine at our shop a few weeks back.  But this stuff, while cool, is way out of the realm of Hobby land.  

Steve

159
Mach4 General Discussion / Re: wx.wxMessageBox question
« on: January 25, 2018, 04:09:20 PM »
The code above has lwx.wxMessageBox().  What is lwx?  A typo?  It should be wx.wxMessagebox.  Probably the macro is failing to compile and it is just running the old stale version. 

Steve

160
Mach4 General Discussion / Re: Is Mach4 really Hobby Material?
« on: January 25, 2018, 03:42:24 PM »
Windows is not real time and thus any application running on it will never close the control loop.  However, Mach can be part of a closed loop system.  Some motion controllers operate in a closed loop manner with Mach.  Galil, Vital System DSPMC, etc...  For a servo system, the loop can be closed in three places, depending on the setup.

1. On the control itself (LunuxCNC).
2. On the motion controller.
3. On the servo drive. 

It you want instantaneous feed rate override, it has to be done at the point in the system where the loop is closed.  That leaves points 1 and 2, as I have never seen it implemented on point 3 (the servo drive).

Hardware based feed rate override is possible on the Galil with a pot connected to an analog input and a bit of Galil DMC programming.  You change the sample period time base (TM) based on the analog value.  However, if you are running servos, this also changes the PID loop sample period so you had better change the PID values to match the new time base as well (just a mathematical calculation).  If you are running steppers with the Galil instead of servos, dealing with the PID values become irrelevant.

All that being said, I would not consider the Galil a hobby controller.  It is more of an industrial motion controller due to its' complexity and price point.  But the option is there.  The higher priced controllers can usually accommodate these types of requirements.  But we are talking about Hobby level machines and controllers, right?  Professional features come at a price. 

Threading...  it needs to be done in the real time component.  No encoder need be involved though.  The motion profile can be, and is, calculated.  The start and end point of the thread never changes.  The challenge is the spindle speed.  If the spindle speed could remain constant, a perfect thread could be produced with a predetermined motion profile.  However, that is never the case in the real world.  So the real-time component of the motion controller must monitor the speed of the spindle and change the time base in which the thread profile is executed to match.  So how does a motion controller monitor the spindle speed?  It can use an encoder.  But a single pulse per rev is usually quite adequate.  It turns out that producing a class A thread doesn't require THAT much monitoring of the spindle speed.  If you have an encoder on the spindle, then use it.  But it is definitely not required. 

Steve