Advanced Search

Thanks for the heads up Rod.

The latest Debian Bookworm live-build version works, once a small error in the auto/config is sorted, as mentioned in a previous post.


I built the ISO on Mint 21.3 and got this in .disk/info
Debian GNU/Linux 12 "Bookworm" - Official Snapshot amd64 LIVE/INSTALL Binary 20240606-02:09

When building on Debian Bookworm apart from the date the file has the same info same.

So I can conclude that the ISO can be successfully built on Mint 21.3 with the current Debian live-build package installed.

The build process removes rpi-firmware along with libre-office, this is in the Linuxcnc-live-build-repo, which is where I started the all from.
After installing from the ISO and updating there was no mention of rpi-firmware being an issue, even runnning sudo update-grub

rpi-firmware is still listed, being marked as residual config indicating that it has been removed but theres some files hanging around. ATM I don't think it's an issue.

Just built live build from source using the instructions you linked to and got this package
live-build_20230502_all.deb Built on Mint 21.3 & Debain 12.5 and package is the same. So I guess that we can conclude the package from debian is the most up to date. Unless of course if you are aware of any branches that are more mature.

After checking against the version I have installed:
rmurphy@ThinkPad-T530:~/tmp$ lb --version
20230502

If you have any more info Rod it would be appreciated.

Just to be sure I've used this to install on:
VirtualBox on 2 different machines.
T61 Thinkpad (just to test that it will install) Core2Duo
HP T610 Plus Thinclient (could be a potential candiate for the Lathe)
Acer Aspire D255 Intel Atom (install process went fine not at all a candidate to run a machine only 1GB ram)
T530 ThinkPad, just testing a live session as no free disk space to install
M72e ThinkStation, with a 3rd Gen i5 it is good (another curb find).
2006 ish Intel iMac.....had to let the install have the whole disk, didn't bother investigating dual boot with rEFInd too far. Just want to see if this thing I found on the curb would work.
Asrock J3355b-tx with a 256GB Evo NVMe on a cheap ebay card, does boot directly from the NVMe, bios sees it as a boot disk.

Tested on USB 2.0 flash drives of 4GB & 8GB and USB 3.0 Flash drive of 16GB.

I'm a bit of a hoarder. Don't really want to try the odroid as it's a pain to get to and running the mill and setup sweet.

Alright, good idea, let's focus on the z-axis homing first. And thank you very much for your help!

I'm running 2.9.2. Previously it was on 2.8.0 pre1 and seemed to be working ok for him. I updated things to 2.9.2 though since I thought it would be good to be on the latest version so hopefully it is.

There are indeed homing switches on both ends of both the y-axis. There's a homing switch on only one end of the x-axis for some reason, and none on the z-axis. Although there are some other types laying around I could install somehow.

Well I think I've only read the Homing Configuration page 4 and a half times so I'll read it a couple more times and see if that works =) Seriously though, maybe some of it didn't make sense to me so I just glossed over it with information overload so I'll work on understanding every single word of it and research it or ask questions if I don't think I understand something perfectly to make sure I do.

"All homing switches MUST stay enabled from the trigger edge to the end of travel"
To be clear, do you mean that as they are being pressed they don't disable until the very end when they are supposed to stop? This is how those particular switches seem to work. They have a wheel on the end of an arm and when pressed the arm will go back until I hear a click and it stops the axis from moving in that direction and then go the other way to their final home position.

The other switches he has laying around he said might be called impedance switches and he couldn't get them to work correctly for some reason. I think he said they had a magnet in them or something that was supposed to detect something when it came close to it but it didn't work. I'm not sure if this is what I should be trying to use but maybe I just have to figure out the right way to use them if they are possible to use.

HOME_SEQUENCE is set to 0 for z, 1 for x, and -2 for both y.

Now that you mention it, at one point I did actually run pncconf to generate some new configs and to try and update the existing configs. It didn't seem to quite work properly to fix the vibration before and maybe even made things worse so I didn't use it. I might have copied some of it into the current configs. I'll have to test this out and see what happens but it sounds like maybe I just have to install a limiter switch at the top of the z-axis and maybe then it'll work ok.

Thank you for all your little tidbits of wisdom!

Here's my hal and ini file.
The whole error is attached too.
 

Means there's an issue with your config, could be a typo.

Posting hal & ini helps.

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.