Advanced Search

Did you try turning off epp_wide mode?

(man hm2_7i90)

I guess some other possibilities are:

Bad parallel port

Wrong base or high address (sometimes the high address is not at the standard 0x400 above the base address)

Bad EPP implementation (this has been seen on some PCI parallel port chips)

You could also  set debug_epp true and see if you get any clues from that

and also check if the parallel port works as expected
 

Its okay if i make the config file with mesa ct?
And i need to make a simple config to test all or how is the correct procedure?
bw I test the ping for 60s and came with 0% of package loss.

I often do 3d wood carving and run the occasional wooden sign. Depending on the size and detail, the files can get very large. And yes, the stock screen preview can be problematic with these files.

Thanks, Cable (20cm length) and board test with other motherboard and run ok, with the asrock motherboard dont run.

Is the 7I90  "BOOT" jumper (W3) set to P?

How long is the parallel cable?

Have you tried it? It should work but you need to share sdos, pdos and configgen xml

Hi, i have motherboard asrock n100dc-itx, setup Parallel port to ecp+epp v1.9 but start lunuxcnc i get error invalid cookie, got 0xffffffff, expected 0x55aacafe, please help me. Thanks.

forum.linuxcnc.org/38-general-linuxcnc-q...ird-behaviour#347456

Duplicate post removed.

If 2.9.8 works for you:
github.com/LinuxCNC/linuxcnc/releases/do...8_amd64_bookworm.deb
Download, double click, open and install with gdebi.

Looks OK, so test with the Mesa attached and a running config.

This are the results
for what i understand are good for mesa Ethernet boards
Now i´m gonna try to make connection to the board
its that okay?
 

After a moment's reflection I do get it. The 2.9.9 bug is serious because it could result in existing gcode not only not working but causing damage. So the 2.9.9. code had to be removed, and as the upgrade process still sees 2.9.9 as the "current" version, update attempts are going to fail.

But I would still like to get away from the 2.9.5 bug, and so my question remains. Is there an easy way in which I can upgrade to a subsequent version that does not suffer from this bug?

Hi everyone,
Could you please advise what to do in this situation:

When reading the PDOs, I see CiA402 indices.

But when reading the SDOs, I get indices mapped at 0x1600 and 0x1A00, which belong to the hardware interface (AIF). This mapping seems to be specific to Lenze.

Previously, the drive worked under CiA402 on a dismantled machine controlled by TwinCAT.

Now, when I try to automatically generate the XML via lcec_configgen, the XML is created with the hardware-specific indices instead of the CiA402 ones.

Has anyone dealt with this mismatch between CiA402 and Lenze’s AIF mapping? Is there a way to force or configure the XML generation so it uses CiA402 indices instead of the hardware-specific ones?

Thanks in advance for your help!

But I'm already dealing with a a bug in 2.9.5, and not being able to specify an offset when touching off the Z axis is a lot more relevant to me than the 2.9.9 bug appears to be.

I presume that I should in fact be aiming for 2.5.6, or perhaps 2.5.7 or 2.5.8. How do I go about upgrading to one of these versions?