Hello Guest it is September 29, 2020, 10:53:59 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

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

scr = require("screenipc)

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.  :)


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.  


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? 


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

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

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


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

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.  


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. 


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. 


Contec / Re: Contec Plugin not working
« on: January 24, 2018, 02:39:05 PM »
The reasons are:

1.  A plugin may require a third party DLL that is not present on the system.
2.  These third party DLLs may require a hardware driver that must also be installed. 
3.  These third party DLLs may also require system DLLs that were not installed at the time the OS was installed.  Or the DLLs may have been removed if the user "stripped" down the OS.  A common one is the Printing subsystem.
4.  A plugin may not be able to "find" these required components (even if they are installed on the OS) unless they are put in the PATH environment variable. 

In all of these cases, the plugin will be reported as "defective".  All that message really means is the plugin could not load due to some missing requirement.  Perhaps the message could be worded a little differently. 

In the case of the Contec cards, the correct PCI driver needs to be installed.  When installing any plugin, the user must ensure that the hardware and associated drivers and software (API libraries) are there for the correct operation of the device.  Most of the time, there are tools that come with the hardware to verify the correct operation.