Advanced Search

Hi,
i wrote a hal component in python to control some I2C devices

*  pcf8574 : Digital IO's
#  ads1115 : Analog input
#  lm75  : temperature sensor
#  hd44780 : LCD display

It is actually part of the RIO project, but can also run independently.
Maybe someone can use it.
It's also no problem to install additional devices. Just let me know what you need; I have almost everything here


Cheers Olli

Link: github.com/multigcs/riocore/blob/dev/rio...ins/rpii2c/rpii2c.py

After a bit of a discussion with forum member f355 it came to my attention that an image based on the "Raspiberry Pi Way" maybe possible. Whilst a little "terse" at first he did raise some valid point and gave me time to reconsider some things. And eat some humble pie. I would like to give thanks for this...sometimes it's needed to find a new direction.

One reason for this idea is to make using the image more familiar to those used to the RPi ecosystem. Being able to use the RPi imager and setup some defaults may be beneficial as well.

At the moment I'm experimenting with pi-gen ( github.com/RPi-Distro/pi-gen/tree/bookworm-arm64 ) target a bookworm based image, as I feel as time moves on and more familiarity is gained using the tool a working image with a RT kernel and Linuxcnc will be produced and can be compared to the existing image. Wifi seemed to be a bit of a issue from time to time.

Hopefully from this in the readme "Tool used to create Raspberry Pi OS images, and custom images based on Raspberry Pi OS, which was in turn derived from the Raspbian project." distribution should not be an issue.

So the first task is to create a basic image to get a feel for the tool.

All input whether positive or negative ( remember coming from Australia I'm somewhat hard to offend ) is welcomed and encouraged. Rather than the way it has happened in the past I would like this to be more of a community effort with regards to packages. Please remember the object is not to create a daily driver OS but one that makes the entry easier to running Linuxcnc on a Pi. Whilst it may be beneficial to include CAD\CAM I feel leaving this out will create a smaller image to download, and as there are many packages available half will be happy, half wont be and the other half may not have a preference.

As a final note the final decision will have to be made by the Linuxcnc hierarchy as I dont want to go against their wishes, but for the moment I think at least a discussion is good idea, and see what the community thinks.

Yes,yes I know some our esteemed members aren't exactly keen (not recommend) on the RPi due to cost factor.

Cheers
Rob

Any issues please post here
github.com/ozzyrob/pi-gen-linuxcnc

So i disabled
#net machine-is-on halui.machine.is-on
in my machine.hal

and did this in my custom_postgui.hal
net MachineLED <= halui.machine.is-on => gladevcp.led_Startstopp

unknown wrote:

Would this be a situation where you would like to give a little more input. 
 

Oh certainly and with pleasure! Feel free to create the new thread and shoot me a link.

1. All of this is my method. I'm not implying it is better or worse than yours, it's just mine.
2. There still is/was a patch that exposed /sys/kernel/realtime that linuxcnc required before 2.9.5, and the kernel is still built from source and baked into the image, as opposed to being installed from an apt repo. That makes the kernel update path unclear to me.
3. I could have asked, but I didn't. I never implied that "those that manage Linuxcnc allow randoms to upload untested content to their server", I'm sure the images are well tested and vetted. All I said is that it is completely non-obvious where the image builder sources are - I've just spent 10 minutes to find them again and I couldn't - and the official github has obsolete sources. That doesn't inspire much confidence in how well those images would be maintained in the future, don't you think?
5. I understand there are differences, it is obvious, I just don't want those differences. I gain nothing by learning how yet another distro is organized, it is wasted brain cycles. Now, your copyrighted branding point makes a lot of sense - I honestly did not think about that, and yes, it certainly adds a huge deal of motivation for not using RPi OS for pre-built images, but as I said even before your point, I totally get why your images exist. You've done a great job, I'm just not in the target audience for your work.

Ok some further research has come up with some utils to build images based on 'the Rpi way".

Some of your comments have caused some rethink of the situation.

Now I think I should eat some humble pie. Would this be a situation where you would like to give a little more input. Consideration of your comments makes me thinks a more "Raspi OS" experience maybe a plus for the next generation of users. A new thread might be a better way to approach this. If you have the time it would be well appreciated.

Kind Regards
Rob

Here comes the "Grumpy Old Man Response".

1: That's your method. I was held back from including gnome network manager, a situation that didn't sit well with myself. Which is great as the user can have the option of enabling and disabling wifi as required. Adding this will be an improvement (as will the turnng off of the power saving features of the wifi, something I haven't recommended as thb I could see it being more hassle that it's worth to describe what is required, delving into systemd is required). Tho I did manage to sneak in gvfs-backends & gvfs-fuse. The zram swap thing was a bit of a debacle, something I blame myself for not fully checking the swap, which did rear it's head. Yes I get the ID Ten Tea award for that.
2: No patch was required for RT_PREEMPT, that was part of the Vanilla Kernel that was selected (which required thought put into it) and many thanks to a certain member that helped clarify a few things regarding that, any patches applied were those that the RPi Foundation has on their github, no trickery on our side. Until their particular patches make it to the mainline kernel they will always be applied.
3: You could of asked. Now this is really the bit I thought was a terrible assumption to make.You think those that manage Linuxcnc allow randoms to upload untested content to their server ? That is something extremely silly to assume, especially with 20 years of Linux experience.
4: Up to you.
5: That's people assuming things regarding the menu config. It has been clearly stated that whilst the image runs on the RPi and the kernel has been sourced via the RPi Foundation, it is Debian at is core and not RPi OS. Someone who thinks critically would assume that there would be differences in how things are done. Not understanding, excepting or realising that that things will always be the same way on a particular platform is rather naive (I would say silly myself).Apart from the kernel and a couple of RPi specific utilities, Debian was the easier solution. Basing anything on RPiOS requires removing a lot of Raspberry Pi Foundation branding from any image that was built and distributed. Hence the reason there was a switch from using Ubuntu in the emc2 days to Debian now.

Being able to actually install Linuxcnc & a required kernel onto a Raspi OS image would have been infinitely simpler, but the copyrighted branding becomes an issue. Which is their right and a good thing as well as it a protection for users, as a lot of people will blindly down load this or that. Hence scammers have it easy.
Supplying instructions for getting Linuxcnc on a Raspi image may have been one way, but people being what people are. I used to be a traffic controller and have lost confidence in people being able to follow instructions or wanting to.

Learned something new there.
Note to self: When saying measure voltage on the work piece, then DON'T MEASURE THROUGH THE PLASMA CUTTER, MEASURE ON THE WORK PIECE. 

I now did that and got the best voltage reading ever, never been that good.
The thing is that the first cut or sensing probe works fine, after that the machine does something internally with the voltage that ruins the coming sensing probes. Just got to measure the tip-work piece voltage closer to the work piece and it should work much much better.
 
 

I now get the cutting voltage into this voltage reader as well.
I'll see what I do with that, it doesn't hurt it in any way. Maybe I can take away the other voltage reader since I obviously now have two arc voltage readers.

 

Hi Tom, after a few months I tried installing this ISO again and everything works even with my old configurations. The only problem is the green spindle speed bar going backwards but the numbers are correct. When stopped the bar is all green then as you increase the rpm it decreases until it reaches the maximum, LinuxCNC crashes and says: spindle speed out of range.

halui.machine.is-on is already linked to machine-is-on

Well, by now you know how to use the signal-name a pin has been assigned to.

Ah, I did not realize the images were yours, I thought it was the great cornholio dude (is that your old account, maybe?) and rodw who worked on them for some reason. That explains your interest in my setup, cool, I can certainly give you some feedback on why I chose RPi OS.

1. as mentioned before, I can't connect to wi-fi without running menu-config, and to run it, I need either a console or Ethernet. Connecting either is a hassle for me, I tend to run my Pi's headless with TigerVNC/noVNC. I've briefly looked at the rpi-image-builder the images are based upon and it seems like it's possible to mount the boot partition and edit some text file there so it sets stuff up on the first boot, but I have not dug deep - with RPi OS I can set that up in RPi Imager, together with the ssh key, the username and other stuff, it's much easier and it just works.

2. The kernel is custom-built from source with an RT patch, which makes it tricky to update it if I ever need to. There are now official RT kernels in the RPi apt repo and I can just apt install the new kernel. In general, the update cadence/mechanisms for the entire thing were - and still are - unclear to me.

3. I couldn't find the git repo where these images are built from. github.com/LinuxCNC/rpi-img-builder-lcnc is 2 years old, rodw's upstream is slightly newer but still older than the published images. It seemed like those images were built ad-hoc once by someone and just uploaded to the server, and that looked like a bit of a red flag to me.

4. cnc/cnc as default username/password is not something I want. I could create a user for myself, sure, but with RPi Imager I don't have to, so why bother.

5. this entire menu-config thing is not what RPi OS uses and what people - myself included - are familiar with. Not a big deal of course, but in general - Raspberry Pi has an official distro that is well-maintained and well-known, and I don't see why I, for one, should use something else in the second half of 2025. I understand why your images were built in the first place - PREEMPT_RT was not mainline at the time, RPi OS tended to push Wayland aggressively, you wanted a turn-key solution that less experienced people could just write to an SD card and use, my headless requirement is rather uncommon, etc., etc., but my personal preferences kicked in and I made a choice.

I hope that clarifies it!

Yes.

The mk mailing list just receives spam, I haven't seen any actual activity for a while.
The Github repos, even the repos that they split, (long story if you want more info on that you will have to read the repos), haven't had any activity for a long time.

Well I was the one that produced the image, so any feed back good or bad (bad seems to be more helpful for improvement) is welcome. That's why I was interested in the reasons for the way you went. Yeah I get it's for personal reasons, but I would like to improve it to make it a better experience for other users and maybe make a consideration for others.

That's the way some threads go, the discussion can go another way. But if you don't want to be involved in the way the discussion as gone, which would appear to be the case, I shall no longer ask for any opinions nor input from yourself.
Good day sir.

Well I have all of the electronics mostly wired properly to the point of testing. I am struggling to get the machine out of estop as my external estop doesn't seem to want to close the circuit even though I thought the relay was closing. More investigation into the schematics are needed and then hopefully I can move forward with the testing

Seems to align time wise:

forum.sheetcam.com/t/the-end-is-nigh-well-sort-of/7103/8

Though looking at the “not sell it to someone who will milk it for what it’s worth” reply, I’m not sure that goal was realized.

My money is on Langmuir, seeing as they sell it on their website …

All good things come to an end I reckon.