Messages

141

Mach4 General Discussion / Re: How many time mach4 check input/output?

« on: June 10, 2015, 11:39:47 PM »

I don't know if the Lua scripts in Mach4 are faster/slower/same as the VisualBasic macros in Mach3, though my gut feeling says the Mach4 Lua scripts will be faster.  I'll leave the true answer to someone else here that has more experience with this.

142

Mach4 General Discussion / Re: How many time mach4 check input/output?

« on: June 10, 2015, 12:35:40 AM »

Short answer: update rate for input signals to the Mach core depends on the plug-in.

Longer answer:
As far as I know (and can remember), in Mach3, 1/10th second (10 Hz) is the rate at which (by default) the plug-in's polling loop ran, with an option for 40 Hz.  *SOME* plug-ins use that polling loop to update the values of the input signals to the Mach core, so for those, yes, the update rate to the Mach3 core was 1/10th second.  However, I think that it is possible for the plug-ins to update the input signals to the Mach3 core at a higher rate, possibly as fast as the hardware can report the input signals to the plug-in.  It all depends on the design of the plug-in (multi-threaded, etc.) and the load placed on the CPU (the Mach3 core is VERY sensitive to how much time the plug-in takes).

Likewise, in Mach4, to my experience, there is a similar polling loop in the plug-in, at least in the sample code from the SDK (from which most plug-ins are derived).  The sample code runs the polling at 10 Hz like in Mach3.  However, Mach4 is more forgiving of plug-ins that run the polling loop at a higher rate (as we do in our PMDX SmartBOB products).  AND...reporting of changes in inputs and outputs from the core back to the plug-ins is done asynchronously from that polling function - i.e. whenever the core is told an input signal changes, it sends a "signal changed" message to all of the plug-ins.  Mach4 is also more conducive to multi-threaded plug-ins, so it is possible that the state of the input signals can be updated to the Mach4 core as fast as the communication channel (USB, Ethernet, etc.) is able to send data from the device to the plug-in.  So, again, it all depends on the design of the device and plug-in.

That said - what functions are you concerned with Mach4 being able to detect and/or change "fast"?  Things like homing, probing and threading are usually controlled by the plug-in (or more likely, the device) itself with minimal coordination with the Mach4 core, because it has to respond to events like probe triggers and home switches faster than could happen if it relied on reporting to the Mach4 core and waiting for a response.

Bob

143

Mach4 General Discussion / Re: MDI movement using G-Code different to jogging

« on: March 10, 2015, 08:23:13 AM »

Rats, no quick solutions off the top of my head.  Since this is heading into detailed debugging of the PMDX-SmartBOB I would like to move this discussion over to our support forums (http://www.pmdx.com/PMDX_Forums).  While Steve and I do try to keep an eye on messages here, our forums are our primary support site.

I've copied the important info from this thread onto our forums here:
http://www.pmdx.com/PMDX-Forums/index.php?topic=72.0

Please go visit there (yeah, I know... and create another account) and we will work to figure out what is happening.

Bob at PMDX

144

Mach4 General Discussion / Re: MDI movement using G-Code different to jogging

« on: March 09, 2015, 01:53:45 PM »

Oops ... Ignore that man behind the curtain.  Motor velocity settings will NOT cause that problem.  If the velocity was too high the DROs would show the correct value and the machine would move less than that.

So, please post your plug-in and firmware information.  And re-comfirm the Mach4 build number.  We have had issues between our plug-in and Mach4 with the latest builds (2255 and 2259), but not 2230.  So this may be some other issue.

Bob

145

Mach4 General Discussion / Re: MDI movement using G-Code different to jogging

« on: March 09, 2015, 12:07:52 PM »

OK - we will need a bit *more* information.  I see you are using Mach4 build 2230.  What PMDX-SmartBOB plugin version and firmware version are you running?  To get this info, go to the "Configure" menu and select "Plugins...", then click on the "Configure" button next to the PMDX-SmartBOB-USB plugin.  The first screen will list all of the relevant info.

Hmmmm....  Now that I look at your post again, a possible cause of this kind of problem is that you have the motor's max velocity set too high.  By default, Mach4 sets the jogging speed to 50% of max velocity.  You can see this when you click on the "Jogging" tab in the lower portion of the Mach4 screen set.  There is a slider at the bottom and a "Jog Rate" box.  Try setting the jog rate to 100% and see if jogging reproduces the same motion anomalies as GCode motion.  If so, go to the "Configure" menu and select "Mach...", then click on the "Motors" tab and try setting the "Velocity" field to a lower value.  If that doesn't fix things, then please post the above info.

Bob

146

Mach4 General Discussion / Re: Mach 4 / PMDX-422 Setup for Dummies

« on: March 05, 2015, 03:49:27 PM »

Well it is obviously because our firmware was written presuming northern hemisphere Coriolis forces 

I have almost no idea.  When it worked running the Mach4Mill profile (with the SmartBOB plugged in), was the machine turned on?

I don't recall which SmartBOB you have.  If it is a PMDX-422 or PMDX-410, you can try changing jumper JP2 (the one right next to the USB connector).  This changes how the board is tied to the USB cable shield.  We ship the boards with the jumper in the "A" position, which connects a ferrite bead between the shield and our GND.  With the jumper in the "B" position, the shield is tied directly to our GND.  With the jumper off, the shield is connected to GND through a 1 Meg-ohm resistor.  See if either of those settings has any effect on the touch pad operation.

If not, I guess maybe try to move the PC and/or the SmartBOB (if possible) to see if that can decrease any interference.

Bob

147

Mach4 General Discussion / Re: Mach 4 / PMDX-422 Setup for Dummies

« on: March 04, 2015, 09:47:29 AM »

I'm running on a laptop. Is it normal for the trackpad to disable when running MACH4? Mine does. But only if the SmartBobUSB is connected.

Hmmmm.... I haven't tried this on a laptop (yet :-).  Our plug-in does nothing that *should* disable the track pad (I presume this is what some people call a "touch pad" and is the thing you drag your finger across to move the cursor, right?).

Is this only when the device is *connected* to the PC, or only when you are running a Mach4 profile that uses the SmartBOB as the motion controller?  For example, with the SmartBOB plugged into the USB port, try running the Mach4Mill profile which uses the SIM plug-in as the motion device.  Do you have the same problem with the track pad?

Bob
PMDX

148

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: March 04, 2015, 09:32:21 AM »

Hi Neil,

There is an issue between our plug-in and the Mach4 core displaying the correct current values of the input signals on startup, though I haven't seen a case where togging the switch hasn't fixed that.  Something seems fishy since only your Z limit switch input refuses to toggle (and only until to enter and exit the config screen).

Since this involves the PMDX SmartBOB plug-in and/or device, please re-post this on our support forums so we can help figure out what is going on.  If this does turn out to be a Mach4 issue we can report that back here.  Please go to:

http://www.pmdx.com/PMDX-Forums

Some of the information we will need:

- Mach4 build number
- PMDX plug-in version
- PMDX SmartBOB firmware version

All of these are available from our plug-in configuration dialog.  Go to the Mach4 "Configure" menu, then select "plugins...", then click on the "Configure" button on the line for the PMDX-SmartBOB-USB plug-in.

Bob
PMDX

149

Mach4 General Discussion / Re: Mach 4 softlimits not working

« on: February 25, 2015, 03:39:55 PM »

This issue has been addressed in the PMDX support forums here:
http://www.pmdx.com/PMDX-Forums/index.php?topic=57.0

Bob
PMDX

150

Mach SDK plugin questions and answers. / Trouble saving plugin cfg from Plugins Control menu

« on: December 23, 2011, 06:04:28 PM »

I'm trying to move a plug-in configuration menu from the Config->Config Pllugins method to installing a "config" menu entry under the "Plugins Control" menu.  I can get my config dialog to display but it never seems to save the changes into the XML file.  I have my code set up to display the plug-in configuration from two places: the origiinal "Config->Config Plugins" dialog by clicking the "CONFIG" button next to my plug in, and the menu entry that I created under the "Plugin Control" menu.  They both call the same routine to display the dialog and update the XML file.

Here is the code from myNotify() which uses the same code to create the DevProf instance that MachDevice.cpp Config() uses.

Code: [Select]

if ( message == MenuRangeStart ) {
   //---  Copied from MachDevice.cpp Config()  ---//
   CXMLProfile *DevProf = new  CXMLProfile(); //start up the Profile class for XML usage. Same as Mach3's.
   //XML reading and writing can occur here..
   DoMyConfig (DevProf);
   delete DevProf;

And here is the code from myConfig() which gets called from the origina

Code: [Select]

void myConfig (CXMLProfile *DevProf)
{
   DoMyConfig( DevProf );
} // myConfig

I have code inside the DoMyConfig() routine that reads back from the XML data (still in memory??) via a DevProf->GetProfileInt() call that verifies that, when I'm done DevProf does contain the new data.  However, if I exit Mach and re-start it (or look at the actual XML file), the data is un-changed *IF* I've gone through the "Plugin Config" menu.  It works just fine going through the "Config->Config Plugins" dialog.

The only difference is perhaps the Mach environment when each gets called (maybe???).  Any hints as to what I may be doing wrong or how to get the changes saved into the XML?

Merry Christmas and Happy Chanukah
Bob