@zaneclaes We appear to be seeing some noise on the serial line from the boot of the arduino in this case. which I have seen as weird memory in previous work, but I’m not sure the cause in this case. The windows serial port filters it and recognizes the due, but the rpi port passes it on and reports no maslow is present.
I got it to connect with some effort. Makerverse on PC can see and communicate with due, but raspberry pi cannot. respberry pi has been replaced. same issue. With minicom, verified due is present, reset the eeprom, established communication, but random garbage is being transmitted. Could be a corrupt arduino or bad USB shield or ground loop, bad solder connection… lots of things. Here is what it looks like and why makerverse doesn’t pick it up.
it is on a Pi 4 4gig, Makervers v1.1.1 {a-master] #167
It is running makerverse image. The rpi will not see the arduino at 38400 bps. I got on and remote controlled a little last night, reflashed the firmware to run at 115200 on the due and it connected to makerverse on the raspberry pi, but intermittently would get garbage with the error: 2 message as we were looking at the calibration page, which is why it is greyed out.
I checked the beta test box in the general settings, saved it and closed out, but when relaunching it, the launcher exits,
where on my machine it continues to show me program feedback.
When restarted no new downloads start and the saved settings did not persist. The due added last time was not saved, so each time we started makerverse, we would have to re add the due. The .makerverse file was there. I copied my file on to his machine and my 3 cncs did not show up, so I’m not sure where the .makerverse file was being stored and why the changes would not persist. My only thought is that it is in the root folder, but the service shows the user is pi, so I’m not sure what the deal is. Can you help out with this? We went so far as to git clone, stop the service and run from a different download, but it still did not work. The 49 rules file is in place and as it should be. I think it is the makerverse image issue, but not sure if it is a permissions or a docker simlink or something else I’m not fully fluent on… and which release do you download for the rpi if you don’t want the whole image?
That is all the details I have for now. @Bryan_Jochumson has more screenshots we saved if they would be helpful. thoughts?
That version is very old. I wouldn’t expect it to work at all.
What are the contents of cat /home/pi/.makerverse? Also, what are the ownership permissions (ls -la /home/pi/.makerverse)? It sounds like that file is missing, or it cannot write that file.
I don’t know how you set up this pi (you mentioned a git clone?) but the bin/launch script may also be out-of-date. You can check bin/launch --version to ensure it is at least v0.2.
You also placed the code in a different directory — the directories you’re using don’t match the instructions (or the Raspberry Pi image). Specifically, the project seems to reside in /home/pi/mv instead of /home/pi/makerverse. This shouldn’t make a difference, but it jumps out at me as nonstandard and calls into question how the installation was performed.
When I first set up the pi I just downloaded the .img file on Sep 14th from gethub and flashed it to a card. The software also seem to think it is up to date and won’t update.
I would be glad to download a newer img and flash it, if it is available.
the .makerverse file was owned and created by root, which I thought was curious. I changed its permissions to allow everything. There were 3 or 4 lines in it:
{
“watchDirectory”: “/home/node/gcode”,
“accessTokenLifetime”: “30d”,
“allowRemoteAccess”: true
}
looked very similar to the start of my file.
I would have thought checking the prereleases beta channel would have triggered an upgrade attempt, but it wasn’t saving. This would be the first thing to fix…
I put it in mv because makerverse folder was already there and running it from mv folder works fine on my system.
The docs are very vague on which version to download if you have a raspberry pi. You get the desktop image, the lite image, or in the docs it does say use linux service and in the linux service, it tells you how to start it, but it does not state which tar.gz release file set to download and decompress to make that happen.
so this was my process to select:
I steer away from the i686 and x86 and 64bit versions because the raspian is 32 on an arm processor. the version left (ia32) did not work.
In the docs, there is no mention of which distro linux version will work on the raspberry pi. I’ve been known to miss stuff though, so I’m sorry for the remedial help requests. Maybe we could make that a little more specific since the rpi will be a supported platform and not everyone will be doing an image install.
The fact that it was owned by root sounds like the file was created by a very old Raspberry Pi image. If it were created that way (the old approach) it would cause the symptoms you describe.
It sounds like you’re looking for this section, at the top of the Web Server install: Web Server | Makerverse Docs
Start by downloading the Source Code from the latest release (or clone the git repository).
Just shows places where the docs could be clearer I’ll clean that up a little more.
Anyways, yeah, doing a sudo chown pi:pi /home/pi/.makerverse should make the file writable and the settings save.
I also plan on making the current version the “official” (non-prerelease) soon, so people installing for the first time won’t end up in this situation.
I did do sudo chown pi .makerverse, so in ls-al it showed pi root, but still didn’t save. Thanks for your guidance on this. It seemed like a permissions issue, but figured I it would update if we checked the box, but this hangup stopped that. Perhaps we should have deleted the file and had it remake it after launching it manually as pi user?
@Bryan_Jochumson will have to run it since it is on his system if he hasn’t already reimaged the card. I was merely telling you which command he/we tried yesterday that didn’t work and now I know why, which will come in handy later.
Ah, got it. Yeah, when doing a chown, you usually want pi:pi instead of just pi (or whatever the username is). The second half tells it to also change the user group to pi.
I’ll clean that up a little more.