Advanced Search

Yeah, I do have the hal_op5_io.so file in that directory.
Now I'm getting this error:
Thread 'base-thread' not found.
does it mean something wrong with my hal_op5_io?

Do you get any errors?
Could you post your .hal and .ini files or the compressed machine config folder?

Now I'm wondering if I need to edit the .HAL file for the built in parport tester as mine isn't at 0x278 or 0x378? How would I even do that if thats what I need to do?

I've got to
usr/share/doc/linuxcnc/examples/sample-configs/apps/parport

but when I open the .hal files for both options or base.hal I can't see where I would change the parameters to fit my set up

Thanks again guys and sorry for being annoying, I am trying to give as much info as I can 'my head hurts' hahaha

I just want to get the parport tester working then I can move onto the rest later.

I dont think you can just reduce one for the other, but its also something I wouldnt know how to do anyways. which is why I keep suggesting to you, that the you should keep using the version you have now.

Be sure you are running Linuxcnc 2,9.2 (or at least 2.8 or higher) to get support for your tandem axis
This will mean you must have homing switches installed on the 2 Y axes.
Then, read the section in the docs titled Homing Configuration about 5 times!
Your Z axis should have a switch at the top of travel.
All homing switches MUST stay enabled from the trigger edge to the end of travel
HOME_SEQUENCE in your ini file controls which axis is homed first (and which axes are treated as a joint axis (eg your Y)

Dont forget that pncconf will create a working config if you change linuxcnc versions.
 

If you can run the Debian 12.5 version, there is a script on the linuxcnc web site to install linuxcnc 2.9.2
Follow these instructions (11 & 12 do the linuxcnc install)
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing

Also using;

sudo dmsg | grep parport

I get

[ 3.711498] parport_pc 0000:02:00.1: enabling device (0100 -> 0103)
[ 3.711658] parport0: PC-style at 0x3028, irq 16 [PCSPP]
[ 3.816893] lp0: using parport 0 (interrupt-driven0

_________________________________________________________

Unsure if relevant. thanks

I'm pretty sure the live build debs are buggy and introduce the raspberry firmware bug that was in Debian 12.0 (fixed in 12.1) even if you are running a later version.

It is therefore best to build live Build from source as described in the live build manual live-team.pages.debian.net/live-manual/html/live-manual/toc.en

The source is much more current than the 02 May 2023 the deb is date stamped.

Note that LB will build for the Debian Version on the host the ISO is built on so be sure your PC is current.

Hey mate, back again

So adapter in and according to what I can see using the terminal the card can be seen by Linux and it has the correct name of chip etc but its still not working using the parport tester below Ill print out what the terminal give me when I type (sudo lspci -v)

_______________________________________________

02:00.1 NON-VGA unclassified device; Oxford Semiconductor ltd 0X16PCI954 (quad 16950 UART) function 1 (parallel port) (rev 01)
subsystem; Oxford Semiconductor ltd 0X16PCI954 (quad 16950 UART) function 1 (parallel port)
flags; medium devsel, IRQ 16
I/O ports at 3048
I/O ports at 3040
I/O ports at 3000
memory at ce900000 (32-bit, non-prefetchable) [size=4k]
Capabilities; [40] Power management version 2
Kernel driver in use; parport_pc
Kernel modules; parport_pc
_______________________________________________

I'm assuming is the issue is the (non-VGA unclassified device) part? as all the rest looks good, I've been looking around and can't find a similar issue.

thanks again guys.

I figured it out, the CMM-EC02 does not include the FMMU Sync Manager bindings in it's EEPROM; which isn't writable through TwinCAT, nor the Beckhoff EtherCAT configurator; though it is possible to write, and commit using .
To generate the file, you'll need  siitool , and the ESI file from Delta.
You'll likely need to modify the ESI file to get the right PDOs if you want to use it with TwinCAT, since the official ESI file lacks some standard PDOs at the time of writing, furthermore, to avoid a slip-up, I removed all cards except my own revision from the ESI file.

The command to generate the binary from the ESI XML file is:
The next step is taking a backup of the SII data from the CMM-EC02 card for safety:
To compare the files, you can use (the first command outputs the original, the second the modified sii data):
To actually write, you can use (editor note: don't use --force, since it likely means something's wrong with the SII file):



The reason for the discrepancy is that TwinCAT uses the ESI file to find the Sync Manager addresses for the MS300, which is correct, while the EtherLab master uses the MS300 SII data, which apparently is incomplete (as hinted at by the warning and error messages from )

I am not sure what the python does as I don't use py.

I guess that the 'canon' is reference to 'canonical machining functions', but I don't know how python is linking into the rs274 interp.

A few years back I wrote a gles2(and gles1 before) backplot (actually with full machine sim for genserial robots) for the rpi zero but I guess it was even worse than the python stuff, I never really got further than a proof of concept.

I actually removed all the python code from linuxcnc and was going to add a dlopen call so modular code(any language python or not) could be used for handling external offsets or whatever it was(I forget what it was as its so long ago).

Anyways I think that what happens is the rs274 interpreter is called and handles the gcode (lcnc has variables scales offsets etc. blah) and spits out the interpreted gcode as  line, move, or arc with xyzabcuvw coords and feedrate. that is what is used for plotting.

From what I remember doing I hacked the rs274 interpreter to output to a file, but had to run the program, that interpreted the gcode program, which was then used to create a backplot.

I did not really finish but the backplot seemed to be roughly the same as the realtime plot, although I think there may have been some error due to accessing c++ classes as c structs(I was planning to remove c++ libs from the system).

I think that the whole backplot is probably inaccurate as it does not simulate what may occur on a realtime machining operation with latency?

I had some idea about what could be done to make an accurate simulation but it was too much effort to bother trying to code.

What I thought should have been done was show a backplot with possible error margins due to realtime latency found by the latency test (although I guess in reality this is probably so small it makes no difference for most machining as there are much larger errors due to the machine?).

I got bored and too busy so never got further than a very basic athena based display program.

I think xemc maybe could have some information on how to get backplot data, but I think that is written in TK and I never had more than a quick lookm at it and it seemed easier to check the code in rs274.

I think everything I am saying maybe irrelevant to python backplots, and its so long ago I have forgotten most of it.

 

GRUB_CMDLINE_LINUX_DEFAULT="quiet isolcpus=1 acpi_irq_nobalance idle=poll"
 

I seem to have most things running. I still need final calibration.

Current problem is although I can jog around using the mouse and software keys I can not run a file nor turn on the spindle.

I think I have things correct but this eludes me, any ideas where I have gone wrong?

for 1 do you mean add it here??
 

this I have no idea how sorry still a rooky
2. launch the pinirq script at startup (there are a couple of ways to do this
easiest may be with crontab)
 

I am in Ottawa Canada, a bit of a drive.