Advanced Search

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

QtPlasmaC uses digital-out-01~03 internally so digital-out-00 is the only free pin available unless you add extra pins with num_dio when loading the motion module:
linuxcnc.org/docs/2.9/html/man/man9/motion.9.html

 

meister wrote:

No comment's, even in the video

Well, i did leave a comment there...
Very nice, thank you.

Hi. I'm using Andy Pugh's Gearchanger and I've come to a point where the spindle will engage, the commanded output on the gearchange signal is correct but it refuses to engage the low gear selection. Would be nice if someone could to sift through my config. and give me an idea of where I messed up. It just always engages high gear no matter what speed is commanded. 

The mill is on a 7i96s with a c13bob on the extender port. I'm using 2 relays on the bob outputs to activate air solenoids to set gears. Running on Probe basic 2.9.

Thanks.




 

Address should be 0xd800
Also try the other address if this does not work.
Do reboot the PC after address change and failed tests

I thought the relay on those 5 Axis BOBs was pin 17, not 14

Not only am I a "newbie" to LinuxCNC, but I am a convert from the Land Of OpenBuilds/ Arduino... so please bear with me, ok?

I have built a 60x54 inch plasma table which used to be run by an Arduino Mega 2560; after becoming disillusioned with the limitations of GRBL (like how difficult it is to add a THC that actually works, it's small sub-set of G-codes & virtually non-existent M-codes), I decided to make the switch to LinuxCNC. 
I re-built an old Dell Optiplex 755 (Core2Duo, 2.8 gHz) running Debian 12 with 4 gb of RAM; the kernel is the 5.4.258-rtai-amd64, and I am running LinuxCNC 2.9.3 from the linuxcnc repository. 
The Dell has an on-board parallel port (0x378 IRQ 7) and a ASix Electronics A91100 PCIe parallel port card (0xdcf0 IRQ 11); they are both recognized and functional.  Surprisingly, the card did not need specific drivers -- I simply added a conf file in the /etc/modules-load.d directory setting the port addresses & IRQ's and it worked perfectly.
The two parallel port break-out boards are SainSmart ST-v3 5-axis parallel controllers; you can see from my machine backup .HAL file how they are wired, physically.
My plasma cutter is an Everlast PowerPlasma 82i, and I am using a "brain-dead" THC designed by "Swolebro" (Arduino Mega 2560 based) and QtPlasmac running in Mode 2 (just up-down signals from the THC).

A backup of my machine is attached to this post for review.

My problem is that the torch triggers when it shouldn't:
1.  On plasma power-on if LinuxCNC is already running;
2.  On LinuxCNC power-on if the plasma is running when LinuxCNC loads;
3.  On computer power-up if the plasma is running when the PC starts;
4.  After cycle start, after the torch initially fails to fire at pierce height on an M3 S1 G-code, it fires when I press Cycle Stop.

The torch WILL NOT trigger when:
1. Cycle is started, torch probes, then rises to pierce height but the torch will not fireon an M3 S1 G-code -- but the cycle continues to run motion;
 
However, the torch will fire perfectly when Torch Pulse is pressed.

My plasma switches ground from the plasma for the torch-on, and my wiring is "Torch On -" wire from the plasma input to relay common and "Torch On +" wire from the plasma input to relay "NO" terminal.  The fact that Torch Pulse works perfectly tells me that my wiring is correct.

A run of HAL Scope show that plasmac.torch-on was not being switched at all -- it was a flat line throughout the M3 S1 command until I hit Cycle Stop; only then did it ramp, at least until the Everlast's 3-second rule shut the torch down.

Perhaps one of you "gurus" can figure out what the problem is?  That would really be appreciated!

John Carter
CCW Transport Services Inc.

 

I dont really know what you mean though. I guess the docs might imply that the upload_config.py is included in tftpy the way they are worded. The upload_config.py is included in every ethernet config.


github.com/scottalford75/Remora-RT1052-c...sic/upload_config.py
github.com/scottalford75/Remora-RT1052-c...DMA/upload_config.py
github.com/scottalford75/Remora-RT1052-c...sic/upload_config.py
github.com/scottalford75/Remora-NVEM/blo...sic/upload_config.py

Yes, I would expect so. More inductance means it takes longer for the last-used field to drop in current and the just activated field to ramp up the current.
Jon

I've been thingking about adopting LinuxCNC for a new to build Router / Mill and I am reading a bit through some documentation.On: linuxcnc.org/docs/stable/html/user/user-concepts.html I read 1.4 and wonder if this is (still?) correct.

1.4. Planning MovesMake sure moves are long enough to suit your machine/material. Principally because of the rule that the machine will never move at such a speed that it cannot come to a complete stop at the end of the current movement, there is a minimum movement length that will allow the machine to keep up a requested feed rate with a given acceleration setting.The acceleration and deceleration phase each use half the INI file MAX_ACCELERATION. In a blend that is an exact reversal, this causes the total axis acceleration to equal the INI file MAX_ACCELERATION. In other cases, the actual machine acceleration is somewhat less than the INI file acceleration.To keep up the feed rate, the move must be longer than the distance it takes to accelerate from 0 to the desired feed rate and then stop again. Using A as 1/2 the INI file MAX_ACCELERATION and F as the feed rate in units per second, the acceleration time is ta = F/A and the acceleration distance is da = F*ta/2. The deceleration time and distance are the same, making the critical distance d = da + dd = 2 * da = F2/A.For example, for a feed rate of 1 inch per second and an acceleration of 10 inches/sec2, the critical distance is 12/10 = 1/10 = 0.1 inches.
For a feed rate of 0.5 inch per second, the critical distance is 52/100 = 25/100 = 0.025 inches.

I interpret this as:
Suppose I have some CAM software that outputs arcs or (bezier) curves as a whole bunch of short linear moves, then LinuxCNC would not be able to keep up it's feedrate because it is not able to look ahead in the buffer, does not not know the vectors are nearly colinear and therefore it does not go faster then it would be able to stop at each coordinate point in the curve.

Chapter 2.10. [TRAJ] Section seems to suggest otherwise. I references to blending corners and an example of looking 50 vectors ahead to deterimine speed and when to decelerate.

This chapter 1.4 also contradicts with chapter 1.3 and G64 with the "Blending modes" just above it. Is 1.4 still relevant, or is it some old part of the manual that did not get revised properly?

found a hiccup we are working out and will push an update when we have it resolved!

No comment's, even in the video

fixed some settings based on the driver manual
steps per rev 1600
microstepping 8

no change in behavior

I have experience with linux and used Mach3 for years... new system so no mach conf file to start with

Running on a 4 yr old pc... pcie paralell card
ST-V3 Breakout Board
DM860T driver
lcpci -v gives me this
01:00.2 Parallel controller: MosChip Semiconductor Technology Ltd. PCIe 9912 Multi-I/O Controller (prog-if 03 [IEEE1284])
    Subsystem: Asix Electronics Corporation (Wrong ID) PCIe 9912 Multi-I/O Controller
    Flags: bus master, fast devsel, latency 0, IRQ 18
    I/O ports at d800
    I/O ports at d480
    Memory at feafb000 (32-bit, non-prefetchable) [size=4K]
    Memory at feafa000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: <access denied>
    Kernel driver in use: parport_serial
    Kernel modules: parport_serial

step conf settings
parport base address of 0 or d800
driver type - other
Step Time 5000
step space 5000
direction hold 10000
direction setup 15000

testing Z axis only
pin 6 Z step
pin 7 Z direction
motor steps per revolution 200
microstepping 2

when I  test the axis I hear the relay click on the breakout board and the motor locks so that I cannot turn it with my hand but I get no movement

Not sure where my issue is... think I am close but not sure where to go next

 

I see so it's probably much, much easier to go out and buy a standard monitor (with tochscreen) and keyboard und just connect those to the base pc. Plus, I think I could sell the Heidenhain components and get a bit of money back that way.