Messages

1

SmartBOB controllers and dedicated accessories / Re: Wiring between PMDX424 and Leadshine servo drivers M452

« on: July 13, 2017, 11:49:38 PM »

Answers also here on our FAQs http://faq.pmdx.com :

How should I connect PUL+, PUL-, DIR+ and DIR- on my motor drivers?
http://faq.pmdx.com/content/5/11/en/how-should-i-connect-pul-pul_-dir-and-dir_-on-my-motor-drivers.html

Should I connect the "Enable" input on my motor drivers?
http://faq.pmdx.com/content/6/9/en/should-i-connect-the-enable-input-on-my-motor-drivers.html

2

SmartBOB controllers and dedicated accessories / Re: PMDX-424 driving Gecko G214

« on: December 19, 2016, 02:12:15 AM »

The PMDX-424 can source or sink 24mA per output pin.  That means that each of the "COM" terminals on J7 through J11 can source or sink 24mA.

3

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: Relay LED on, no continuity

« on: December 19, 2016, 01:58:10 AM »

Oops - one more thing.  You have OUTPUT #1 and OUTPUT #2 configured as active low.  They should be configured as active high.  In the config dialog, click on the "Output Signals" tab and click on the green check marks in the "Active Low" column to change them to red "X"s.

Bob

4

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: Relay LED on, no continuity

« on: December 19, 2016, 01:51:39 AM »

I took just a quick look at the Mach3 XML file.  You have the spindle STEP and DIR signals mapped to Pin 14, as well as OUTPUT #1 and OUTPUT #2.  And OUTPUT #1 is controlled by M4 and OUTPUT #2 is controlled by M3.

So you have the spindle step signal (which is actually a PWM signal) fighting with the spindle DIR signal, fghting with M3 fighting with M4 for control of the pin 14 output.

If your goal is to have pin 14 go high (and thus energize the relay) whenever the spindle is running, do this:
(1) in the config->Ports&Pins, go to the "Spindle Setup" tab, and un-check the "Use Spindle Motor Output".  That will disable the spindle step/dir signals.

(2) It has been a long time since I've run Mach3, and I am not sure how it behaves if you have outputs for both M3 and M4 driving the same output pin.  So I would suggest at least for now that you disable "Output #1" in the "Output Signals" tab.  This will allow M3 to turn on the relay, and M4 will behave like M5 and turn off the relay.

This should allow the K2 relay on the PMDX-126 to work.  Once you have that working we can talk about supporting both M3 and M4, and possibly getting your PMDX-107 installed (which may help here).

Bob

5

SmartBOB controllers and dedicated accessories / Re: Different types of probe connections (NO vs NC)

« on: December 15, 2016, 09:59:29 PM »

As it turns out, the simplest method is to use the Lua script option.  There is a spare empty button on the main screen so I used it for the toggle probe function and just set the button to toggle the input activelow state.  On experimenting, you don't have to be disabled to do it but I did limit it to only function in an idle state.  Was a bit surprised that it even saves the state it's toggled to in the .ini file.

Are you calling mcCntlConfigStart() before you change the polarity?  And mcCntlConfigStop() afterwards?  These function calls are necessary to tell the SmartBOB plug-in that the configuration has changed.  If you are not calling these functions, the plug-in and SmartBOB device will no know the configuration has changed and they will continue to use the original setting.  And since the probe "touch" detection is done in the SmartBOB device, it will not work for the probe after your Lua script toggles the polarity.

The SmartBOB plug-in only sees changes in configuration when you:
(1) Start Mach
or
(2) Open any configuration screen and then close it, which causes the Mach4 core to send all plug-ins an "end of configuration" message which tells us that we need to re-read the config data.
or
(3) A plug-in or Lua script calls mcCntlConfigStart() and mcCntlConfigStop() (which generates the "end of configuration" message just like a configuration dialog does.

Bob

6

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: Relay LED on, no continuity

« on: December 13, 2016, 11:47:03 PM »

From your original post:

Attempted a work around  and purchased an arduino compatible relay board. Ran it up on J6 pin 14 after removing jumpers from JP1 and JP2. Same behaviour. LED lights though no 'click' or continuity.

Do you mean that when you connected the Arduino relay board to J6 on the PMDX-126, the relays on the Arduino board also did not close their contacts?

Bob

7

SmartBOB controllers and dedicated accessories / Re: Different types of probe connections (NO vs NC)

« on: December 09, 2016, 02:29:24 AM »

For now your choices are to add an inverter such as the transistor circuit you mention, or try to create a Lua script that changes the polarity of the PROBE input.  I don't *know* that this can be done in Lua, but I see function calls that should make it possible.  See the Mach4HobbyDocsMach4CoreAPI.chm file and look in the "API Reference by Category", then in "Mach Signals" for functions mcSignalGetInfo and mcSignalSetActiveLow.  You will most likely need to make sure Mach4 is disabled when you call the "set" function.  And there may other functions you need to call, such as in the "GUI" section, the ncCntlConfigStrart (before you can call the "set" function) and mcCntlConfigEnd (when you are done making changes).

There is a facility in Mach4 to support multiple probe inputs (4 in total), with each one able to have its own active high/low setting.  On the Mach4 configuration dialog in the "Input Signals" tab there is a "PROBE" input, which you are currently using.  If you scroll further down you will see "PROBE1", "PROBE2" and "PROBE3".  The G31 command uses the "PROBE" input.  Mach4 added "G31.1", "G31.2" and "G31.3" variants to use the "PROBE1", "PROBE2" and "PROBE3" inputs, respectively.

Alas, the SmartBOB plug-in does not yet support the additional 3 probe inputs nor the G31.x variants.

Bob

8

SmartBOB controllers and dedicated accessories / Re: 424, 407, Mach4 Lathe not homing

« on: December 09, 2016, 02:12:45 AM »

This is a known issue with profiles cloned from the default Mach4Lathe profile from build Mach4 build 3206 or later.  There is a work-around for this in an upcoming SmartBOB plug-in release, but that doesn't help you now.

If you are semi-handy with a text editor (Notepad, or whatever you like to use but NOT a word processor like Microsoft Word), you can fix this yourself.  I will presume that you have installed Mach4 in the default location of "C:Mach4Hobby".  If you installed it somewhere else, substitute your actual install directory in the steps below.

(1) Open "MyComputer", or Windows Explorer (not Internet Explorer) and navigate to this directory:
         C:Mach4HobbyProfilesYourProfileName
where the "YourProfileName" should be replaces with whatever the name of the profile that you are using (such as "MyLathe").

NOTE: If you are using "Mach4Lathe" as your profile, PLEASE MAKE A COPY! This profile name WILL BE OVERWRITTEN should you ever re-install Mach4, or install any newer version of Mach4.

(2) Look for a file named "Machine.ini".  Open that file in your text editor.

(3) Search for all instances of "CanHome=0" (without the quotes).  Change them to "CanHome=1" (again, without the quotes).  There are usually 3 occurrences.

(4) Save the file and exit your text editor.

(5) Start Mach4 and try to home your machine.  You should be able to home the machine now.


Here is how to make a copy of your profile:
(1) Start the "Mach4 Loader" from the icon on y our desktop
(2) Highlight the "Mach4Lathe" profile by clicking one time on it
(3) Click on the "Copy Profile" button
(4) In the "Copy Profile" window that pops up, enter a new name for your profile.
(5) You can leave the "Screen Set" field blank and the new profile will use the same screen set as the original.
(6) Click on the "OK" button.
(7) In the Mach4 Loader dialog, select your new profile name and click "OK" to run it.

Bob

9

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: PMDX 407 with VFD Forward/Reverse

« on: December 04, 2016, 01:54:01 AM »

Here is a picture from the upcoming 407 manual update.  Just squint your eyes and pretend the PMDX-122 in the picture is a PMDX-424, and ignore the power connections to the 407-S.

10

SmartBOB controllers and dedicated accessories / Re: PMDX 424 not detected

« on: December 04, 2016, 01:39:59 AM »

Rats!  And I finally had something for you to try with the probing issue :(

When you say you "tried to reinstall the com port driver", do you mean you re-installed the plug-in (which won't alter the virtual COM port driver if already installed)?  Or did you go into device manager and un-install the Virtual COM Port driver?

Does this PC have an internet connection?  If so, Win10 may have installed updates "for" you that may be affecting the virtual COM port driver.

A couple of things to try:

(1) Power off the PMDX-424 and unplug the USB cable. Press and hold the push button on the PMDX-424 while turning power on.  Continue to hold the button for 2 seconds then release.  You should see a rapid flash on the green right-angle LED.  Connect the USB cable.  Wait 5 seconds.  Try running Mach4.  If you get a "The SmartBOB bootloader is running" warning message, then exit Mach4, power off the PMDX-424 and back on and try Mach4 again.

(2) If your answer above is that you did not go into device manager and un-install the virtual COM port driver (or you have not yet followed the FAQ link I am about to give you), then try the instructions here:

http://faq.pmdx.com/content/3/8/en/how-to-manually-install-the-virtual-com-port-driver-version-14.html

(3) Do you have a 2nd PC somewhere on which you can install Mach4 and our plug-in?  If so, try that and see if Mach4 is able to communicate with the PMDX-424.

Bob

11

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: PMDX-179 Error code light

« on: November 27, 2016, 10:18:33 PM »

When connected to a PMDX-424, the PMDX-179 "Probe" LED only illuminates when probing motion (G31) is in progress.  This was done because Mach4 supports 4 different probe inputs (PROBE, PROBE1, PROBE2 and PROBE3).  And we don't know *which* probe signal is the selected one until we see one of the G31 commands (G31 for "PROBE", G31.1 for "PROBE1", G31.2 for "PROBE2" or G31.3 for "PROBE3").

Currently the SmartBOB plug-in and all SmartBOB devices only support the PROBE signal and the plain "G31" command.  We *may* be able to assume that PROBE is the input to monitor.  I'll have to look into this to make sure that is the way to go.

Bob

12

Parallel Port breakout boards, motherboards, and dedicated accessories / Re: PMDX-179 Error code light

« on: November 27, 2016, 01:42:26 AM »

Oops - we've out-smarted ourselves.  Originally that LED was labeled "Status", to match the silkscreen label on the PMDX-126 board.  Somewhere along the way (long before the PMDX-424 existed) we changed the text on the PMDX-179 panel to say "Error Code" but didn't update the PMDX-179 manual, which in table 5 on page 8 still calls this "status" (well, calls the corresponding signal on J3).  The change to "Error Code" is because when used with a PMDX-126, that LED really only turns on when there is an error, or when the test button is pressed.

However, when the PMDX-179 is used with a PMDX-424, this LED really is (mostly) a status signal.  A slow flash (on for 1 second, off for 1 second) means that the PMDX-424 is is running normally and communicating with the SmartBOB plug-in.  One short flash every 2 seconds means the PMDX-424 is running but not communicating with the PMDX-SmartBOB Mach4 plug-in (usually this means that Mach4 is not running).  Any other flash pattern indicates an error and you then need to look at the LEDs on the PMDX-424 to determine what caused the error.

Bob

13

SmartBOB controllers and dedicated accessories / Re: Mach4 and probing

« on: November 16, 2016, 03:01:22 AM »

Two things:

(1) It appears that you have the modbus plug-in enabled, and configured to talk to a TCP device at IP address 127.0.0.1 (i.e. this is the TCP "loop-back" address which means the same PC).  Is this intentional?  Do you have a modbus program running on your PC?  I ask because the debug log that you sent is flooded with messages that originate in the modbus plug-in that, in my experience, happen when the modbus plug-in cannot connect to the TCP device.

I don't *think* this is the cause of the problem you are seeing.  This should only be an issue because our plug-in is spending a not-insignificant amount of time dealing with these messages and that *may* be affecting other behavior in our plug-in.  In fact, ALL of the plug-ins are seeing these messages.  If you are not intentionally trying to use a modbus device, please go to the "Configure" menu, select "Plug-ins" and then the "Modbus" plug-in.  In the Modbus dialog, click on the 2nd icon from the left (if you hover over it, it should say "Remove a MODBUS Connection" to remove the unused connection.  Then click on "OK".

(2) In the log file (thanks), I can see the probing motion starting, the probe touching, the probing motion stopping, and the end of "GCode Running" (the probing command, I presume).  All good, so far.  I then see another GCode motion start (I presume this is the MDI command "G 90 F 10" that is shown in the Mach4 log that you sent), and then I see someone else telling Mach to stop.  This does not originate from our plug-in, and unfortunately there is no way to tell WHERE that came from.

SOOoooooo... where to go from here?  The easiest things to try, and to give me time to think of something else to try, are these:

(a) Leave the P2S pendant disconnected.  Go into Configure->Mach, click on the "Plug-ins" tab and disable the P2S pendant plug-in.  Exit Mach4 then re-start it.  See if the probing behaves any differently.

(b) If you still have the probing issue in (a) above, and if you are comfortable using Windows Explorer (or "My Computer") to move files around - Exit Mach4.  Move the P2S pendant plug-in files from the "Mach4HobbyPlugins" directory into some other directory.  I usually create a directory inside the "Plugins" directory called something like "temp" and move them there.  These should be "P2Spendant.m4pw" and "P2Spendant.sig".  Now start Mach4 and run the probing again and see if there are any differences.

After these experiments, restore the P2S plug-in files into the "Plugins" directory and re-enable the P2S plug-in in Mach4, to get things back to your original configuration.

Bob

14

SmartBOB controllers and dedicated accessories / Re: Mach4 and probing

« on: November 14, 2016, 09:32:46 PM »

I'll look at the profile a bit later.  Meanwhile, if you see this message and have the time, try this same sequence without using the pendant.  I have been some issues with some versions of the P2S Mach4 plug-in causing invalid motion data during jog moves.  And while I haven't seen it cause this exact problem (with probing after a jog), I would like to try and rule that out.

What version of the P2S plug-in are you running?

And did you capture the Mach4 diagnostics log window messages?  At a quick glance I didn't see anything that looked like that in the profile package.

Bob

15

SmartBOB controllers and dedicated accessories / Re: Mach4 and probing

« on: November 13, 2016, 11:10:59 PM »

A couple of things:

(1) There have been several updates/upgrades to the probing code in the Mach4 core and screen sets from build 3124 to 3206 (the latest public release).  My first recommendation is that, unless there is some very specific reason you are staying with Mach4 build 3124, update to 3206.

BEFORE YOU UPDATE YOUR MACH4 VERSION: if your profile name is "Mach4Mill", copy it to a different name.  Installing a different version of Mach4 *will* overwrite the default Mach4Mill profile.  Likewise, if you have made any changes to the screen set, make sure your screen set has been saved to a name that is not "wx4.set".  And let me know if you have made any changes to the screen set.

(2)  If upgrading the Mach4 builds 3206 doesn't fix this, I'd like you to capture a couple of debug log files.  Most of this process is described in our FAQs here:

http://faq.pmdx.com/content/3/3/en/how-to-capture-a-debug-log-file-and-send-to-pmdx.html

After enabling our debug log, exit Mach4 and re-start it.  Then display the Mach4 diagnostic log by going to the "Diagnostic" menu (not the "Machine Diagnostics" tab) and select "Logging".  When the logging window appears, click on the small right arrow to enable the log.

Now try your probing moves.  When the error happens. save the contents of the Mach4 diagnostics log to a file (click on the "Save" button).  The disable our debug log as described in the FAQ, create a profile package and exit Mach4.  Send (or post here) both the profile package AND the saved Mach4 diagnostics log file.

Bob