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

Pages: [1]
1
Hey Bob-

Here is more more detailed information for you. I have also emailed you my debug and gcode file.

Current Setup:

PMDX-411 > PMDX-126 > G540

Spindle- PMDX-107. Hitachi X200 VFD and a no-brand 3HP spindle

Windows 7 x64 Enterprise
Mach Build 2914
SmartBob Plugin version- 0.41.205
SmartBob bootloader version- 1.8.64
SmartBob firmware version- 0.48.165

After getting the new PC installed last night, I started going through more runs to create the debug logs. I still got weird firmware behavior at first on the new PC. At first launch it asked me to update the firmware. After relaunching Mach4, I would get different errors, but could never get a job to start. A new one I got was "System Error(18): Packet timeout, communications lost".

At this point I went into the plugin config and told it to update the firmware. The update screen showed current and available firmware version as 0.48.165. I told it to download and did the normal relaunch of Mach. At this point I was back to my normal behavior of the PMDX-411 losing communications during the job.

I was still swearing it was noise from the VFD, so I did a run of the job with power completely disconnected from the VFD. At first it seemed to confirm the VFD noise because it went for almost two hours, but then lost communications around line 400,000. If it is of any value, this is the longest the machine has ran on the particular job before failing. With the VFD on the furthest it got was around line 370,000. This test run with the VFD off is what the debug files came from that I emailed over.

The true source of my issues is most likely that I am supposed to leave the state for a month in 5 days and am supposed to deliver the job I've been trying to complete :)

Thanks-

Adam

2
Thanks for the reply Bob. I am trying to replicate it now with debugging turned on. Right after I posted, I air ran my file twice and it lost communications both times. One time was very early on in the job (10-15 min), and the second was about 1.5 hours in.

The current file I'm working with is very large at about 36MB and just under 2 million lines. I have seen this problem on smaller files as well, but just can't replicate as easily.

Another thing to note is this afternoon I went ahead and finished installing a new PC I have had waiting. I wanted to rule out that side if possible and this was a good excuse to go ahead and spend the time to get it loaded.

At a high level the problem screams noise, but the weird firmware behavior and randomness with no environment changes have me puzzled.

I will have some more info over with the debug files if this current run hoses up on me.

-Adam

3
Have been getting some really weird behavior the last few days from my 411. Seemed to run fine for the last few months, so not sure what has changed. Losing communications in the middle of large jobs with errors like "internal Device Error 110" and the normal "Cannot communicate with device".

Then this morning after trying to recover a really important job that it died on last night, I got some crazy firmware behavior. When launching Mach it prompted me to update the firmware. I didn't catch the version numbers it listed. After upgrading it, the machine was completely unusable. I would cycle start a job, the spindle would fire up for about 2 seconds, then Mach would display "Invalid or unknown PMDX-SmartBOB-USB device found". After launching Mach again, the firmware box came back up and said the current version was 0.48.165 and the available version was 0.45.155. This didn't make much sense to me having the version number go backwards.

After that second firmware update (backdate), I could run the machine again. Although 15 minutes into the job, it then lost communications again.

-Adam

4
Right before I posted the question I figured out the issue, but wanted to go ahead and put it out here for reference.

The issue was a faulty e-stop switch. There was about 1/16 inch of play when the button was depressed. One of the two switches was not breaking the circuit unless the switch was pushed past that 1/16 inch of play. This explains the behavior since pressing the e-stop would momentarily break the circuit until the minor spring-back.

Moral of the story is don't skimp on the import stuff. $6 e-stop switch could have caused quite the mess later down the road.

Adam

5
Having some behavior with the e-stop that is abnormal.

If Mach4 is enabled and I press the e-stop, M4 recognizes it and disables. After a second or two (with e-stop still depressed), M4 reads "E-stop cleared". This is confirmed by on the diagnostic screen which does not show the e-stop active.

The second odd scenario is if the e-stop is depressed before powering on the system, both the PMDX-126 and M4 do not see the e-stop triggered.

System Information:
PMDX-411 connected to PMDX-126. (Normally a G540 is connected to the 126 but I disconnected to simplify the troubleshooting)
Mach4 4.2.0.2914 Build 2914 running on XP x86
External E-stop switch is only connected to the PMDX-126.
Input E-stop signal is enabled to the SmartBOBUSB on port 10 with "X" in Active Low.

Thanks-

Adam

6
Thanks for the info Bob. That makes sense. Just tested it out and all looks well. Having some weird behavior with the e-stop, but will start a separate thread for that.

Thanks-

Adam

7
I have a question on getting the charge pump to work with my setup. Here are the details on what I have:

PMDX-411 hooked to PMDX-126

G540 being ran off of the J19 connector on the PMDX-126.

I'm not sure the correct way to set this up. I have tried a couple different ways without luck. The PMDX-126 is expecting the charge pump signal on PIN 17, but the G540 needs it on 16. I thought I could leave the PMDX-126 in normal mode and change the PIN to 16 in MACH4, but that did not get the charge pump signal to the G540.

Any ideas?

Thanks-

Adam

Pages: [1]