Advanced Search

No need it's all done via the ini settings automatically now, it's up and running all sorted out! Enjoy

hanskuster wrote:

Hi all, hi scotta,
I still have a problem with my NVMPG, like in forum.linuxcnc.org/18-computer/44828-rem...rd?start=1710#298883 already stated. I have the same behaviour.
I can control the axis with the NVMPG, switch the axis and scales, but I don't see anything useful on the NVMPG.
Did someone succeed in making the display work?
I use a EC500 with the firmware Remora-RT1052-cpp version 3.1.2.

Regards, hanskuster

Some good news. I've found what's broken the NVMPG... just need to figure out how to fix it. The DMA stepgen implementation is the issue with most likely a channel conflict or something happening..... head scratching time. 

Can we make two sets of configurations to allow users to choose whether the fifth axis is the C axis or the B axis?
Also, can we replace the image in custom_probebasic.py?

Yeah, I've found it at the end. 

Well Friends, I have managed to solve this problem -- with a lot of good diagnostic help from tommylight, PCW and the rest of you.  But, in the final analysis, two old sayings come to mind -- "Read the fine print on the board", and "When all else fails, read the documentation."  I posted a pinout diagram for the SainSmart ST-v3 breakout board in an earlier reply -- and in an inset box, right on the board, was the statement, "Invert P14 Relay in LinuxCNC To prevent the spindle from starting when AXIS starts".  That, of course, set me off on a search of the documentation to find out exactly HOW to invert an output pin.  It turns out that it is a parameter that has to be set with a "setp" statement.

It turns out that the whole problem is that on this particular board design the relay, Pin 14, is set high in hardware and you have to invert the pin to make the relay function properly (like most relays on the market).

These two statements, inserted in the HAL file right before the "# ---JOINT ASSOCIATED WITH THE Z AXIS---" comment:

setp parport.0.pin-14-out-invert TRUE
setp parport.1.pin-14-out-invert TRUE

were exactly what was needed to make the relays on both boards function properly.

The first thing I noticed after replacing the wiring in it's proper order, and powering on the machine, was that the "RELAY" LEDs were no longer lit -- that told me that I might be onto something.  Then, after starting the machine, I powered up the plasma and it did NOT fire.  I went on to run the cut-test program I have; aside from an immediate fault related to loss of ARC OK, it did fine -- I checked "Ignore ARC OK" and resumed.  It ran the whole program, firing when it should, and making some beautiful holes in this sheet of 1/2" mild steel on my table.  I will chase down the ARC OK fault later, when I have time.

So, again, thank you to all of those who offered help, suggestions, and possible causes/ solutions -- it allowed me to follow this to a successful conclusion.

John Carter
CCW Transport Services Inc
Grants Pass, Oregon
 

This ~shouldn’t~ happen, there may be a bug here. Any chance you can post your gcode so I could play around with it when I get some time?

Edit:  it would be helpful if you posted a backup of your config file made from the SETTINGS tab as well, if for no other reason than to know what version you are on. 

Thank you so much ,that's very helpful.

tommylight wrote:

I was pretty sure something is amiss from your detailed explanation, so now we go into "eliminate" mode:
1.
-Plasma OFF
-remove both parallel cables from the BOB's
-BOB's powered OFF
-turn ON plasma
Does it start?
2.
-same as above but BOB's powered ON
result?
3.
-plasma OFF
-plug one parallel cable
-BOB's OFF
-turn plasma ON
-same with the other cable, ONLY 1 cable at a time
4.
-same as above with BOB's powered ON and one cable at a time
5.
Same as above with BOTH cables and BOB's powered OFF then with BOB's powered on
 

OK -- the results are in...

With both cards plugged in but power off == plasma fires when powered on;
With the primary card unplugged (the one the torch is NOT on) == plasma fires when powered on;
With the primary card plugged in and the secondary card (the one the torch IS on) unplugged == plasma DOES NOT fire when powered on;

Same results with one or both cards powered on -- the torch only fires when the card it is on is connected, powered or not.

John

 

@PCW
Do you mean with the LinuxCNC machine off? Yes -- I was just telling Tommylight that I noticed that the RELAY led on both cards is lit even without LinuxCNC running.

Is there a fix for that?

Tommylight, before we get into that, I want to add some information that might give you a little more insight.

After switching the torch to the second card, I noticed that the board LED's for RELAY, IN5 and IN4 on the second card were lit; the RELAY LED on the primary card was also lit. Doesn't that indicate that SOMETHING is sending a high signal to both relays? The IN4 and IN5 are inconsequential -- those are the UP & DOWN pins from the THC. But both relays being powered with no running command or even with LinuxCNC running -- not normal.

Also, after switching the boards, I decided to try to run that program all the way through -- didn't work. The torch probed, didn't light off, moved on, then came on halfway through the 2nd side of the first square hole -- went out in the middle of the 4th side; came on again about halfway through the large circle but went out about 90 degrees further on.

It's almost as if there is something delaying the G-code being actually carried out...

John

Ahh, that is the Sainsmart model without the 0-10V output so
has a different pinout.

Is the relay on when the machine is off? That's an issue with the
other model (and the output state is not guaranteed a power up)

What did "fomer" do to get disabled?
I can not find any post from him, ever, deleted or otherwise.

I was pretty sure something is amiss from your detailed explanation, so now we go into "eliminate" mode:
1.
-Plasma OFF
-remove both parallel cables from the BOB's
-BOB's powered OFF
-turn ON plasma
Does it start?
2.
-same as above but BOB's powered ON
result?
3.
-plasma OFF
-plug one parallel cable
-BOB's OFF
-turn plasma ON
-same with the other cable, ONLY 1 cable at a time
4.
-same as above with BOB's powered ON and one cable at a time
5.
Same as above with BOTH cables and BOB's powered OFF then with BOB's powered on

tommylight wrote:

1. Should happen ONLY if the torch is on in LinuxCNC, otherwise something wrong
2. Happens only if the output is inverted, other possibilities, skipping for now
3. That is normal with parallel ports, see below
4. Again, only if output pin is inverted
If it works with Torch pulse .... well that throws everything out of the window as it makes no sense compared to some above points, or points to some wiring issues or bad interference/potential difference
Things to fix/check:
M3 S1 must also have $0 so it becomes
M3 $0 S1
Parallel ports send status signals on powering up the PC, so that will fire the torch and there is not much to do with built in ports since you are using a BOB, without a BOB it is easy to check what output pin does not change state during boot and use that pin for torch on.
Add on parallel port usually do not send signals at all on boot, so you have the option of using the second card for torch on with BOB
Try using the BOB wired to add on card for torch on, edit the hal file accordingly, do some tests and report back
 

Well, tommylight, no easy fix here I guess; I did as suggested (switched the torch over to the other board's relay & switched it in the HAL file) and... same thing.
I'm curious, though, about your statement about pin 14 being inverted... if that were the case, would there be a way to reset it to a non-inverted state, seeing as it was never intentionally inverted to begin with?  And how did it get inverted if it wasn't intentionally inverted in the HAL file?  What statement would I use to do so?
As for the G-code -- below is a snippet from the test cut file I am using; it was produced by the Autodesk post processor in Fusion 360 (I love that program, but not enough to pay for it!):

(1001 CUT TEST)
(MACHINE)
(  VENDOR JDS GARAGE)
(  MODEL PLASMA TABLE)
(  DESCRIPTION THIS MACHINE HAS XY AXIS ON THE TABLE AND Z AXIS ON THE HEAD)
N10 G21
N15 G90 G40
N20 G17 G91.1
N25 G64 P0.254 Q0.254
N30 M52 P1.
N35 M65 P2.
N40 M65 P3.
N45 M68 E3 Q0.

(2D PROFILE3)
(

---

)
(- NORMAL OPERATION. -)
(

---

)
(PLASMA CUTTING)
(THROUGH CUTTING)

N55 M66 P3. L3 Q1.
N60 F#<_hal[plasmac.cut-feed-rate]>
N65 G0 X84.66988 Y19.8734
N70 M3 $0 S1
N75 G1 X89. Y22.3734
N80 Y29.
N85 X71.
N90 Y11.
N95 X89.
N100 Y22.3734
N105 Y22.8734
N110 X84.66988 Y25.3734
N115 M5
N120 G0 X42.23084 Y17.68223
N125 M3 $0 S1
N130 G1 X46.49632 Y20.291
( End of snippet)

How could this file work with xhc-whb04b-6?