Will LaserWeb Server work on OS beyond Jessie

Hi everyone having read this article I wanted to install the server on my Raspberry Pi to control my laser cutter. However, since it is a Pi 3B+ and according to this chart, Jessie will need at greatest a Pi 3 to be installed (I have already tried installing it on my 3B+ and it didn’t work). Nonetheless, I still went through the setup on my Pi 3B+ with Buster and I was able to connect. However, I have been facing weird issues like the test fire button not working and test cuts randomly stopping etc. I was wondering if I could make the server work on a later OS or do I need to purchase a 3B to run Jessie?

Thanks in advance for any advice!

Regards,
Ethan

Yes, the server will run on Stretch and Buster

I’m currently running LW.comms-server on a Pi3 modelA, a Pi3 ModelB+ and a Pi4/4gb. All of them are running Buster; and are running well. The two Model 3’s ran lw.comm-server on Stretch without issues before they were upgraded to Buster.

Cutouts and interrupted jobs etc sound like a comms problem; what does the log from lw.comm-server itself say when this happens? what does the system log shown by journalctl -f say if you run it while the server is misbehaving? are there any serial or other hardware erros shown? is the system throttling due to heat, orthe Pi’s hideous ability to briefly undervolt.

PS: Buster tip: Make sure your user is in both the ‘gpio’ and ‘dialout’ groups; with Buster the serialport driver used in the server cannot search for USB ports unless it is a member of the gpio group…

1 Like

Hi there, thanks for the reply!

I will try checking both /var/log/syslog and the system log via journalctl -f as you pointed out. As for the user permissions I am using the default pi user but will check the groups that user is in a verify that it has access to ‘gpio’ and ‘dialout’. For good measure I’ll also change the baudrate from 250000 to 115200 as instructed by the guide.

Will do these steps sequentially and see update on whatever findings I get.

Cheers,
Ethan

Yes, that is a good idea to check, and pretty quick/easy :wink:
I’ve had mixed luck running controllers that fast; worked fine on 32bit esp32 and Duet controllers, fell apart with ATMega based controllers. I think the bottleneck is likely to be the usb->uart chip on the controller, not the PI.

2 Likes

Hi all I have tried the following successively:

  1. Changed the baudrate to 115200 and rebooted the boards but no success.
  2. Checked the /var/log/syslog and don’t see anything peculiar about the logs other than the version of Marlin being recognized as RE_NA (I saw this on the gcode terminal of the LaserWeb frontend as well.

Attaching a snippet from the Syslog:

Jun  9 12:41:55 raspberrypi dhcpcd[395]: wlan0: adding default route via 192.168.1.254
Jun  9 12:41:55 raspberrypi lw.comm-server[354]: App connected! (id=0)
Jun  9 12:41:56 raspberrypi lw.comm-server[354]: INFO: Requesting Server Config
Jun  9 12:42:01 raspberrypi dhcpcd[395]: wlan0: no IPv6 Routers available
Jun  9 12:42:03 raspberrypi systemd[1]: Started Session 4 of user pi.
Jun  9 12:42:05 raspberrypi dbus-daemon[376]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' r$
Jun  9 12:42:05 raspberrypi systemd[1]: Starting Time & Date Service...
Jun  9 12:42:05 raspberrypi dbus-daemon[376]: [system] Successfully activated service 'org.freedesktop.timedate1'
Jun  9 12:42:05 raspberrypi systemd[1]: Started Time & Date Service.
Jun  9 12:42:09 raspberrypi systemd[1]: systemd-fsckd.service: Succeeded.
Jun  9 12:42:19 raspberrypi systemd[1]: systemd-hostnamed.service: Succeeded.
Jun  9 12:42:20 raspberrypi systemd-timesyncd[296]: Timed out waiting for reply from 207.148.72.47:123 (2.debian.pool.ntp.org).
Jun  9 12:42:31 raspberrypi systemd-timesyncd[296]: Synchronized to time server for the first time 178.128.28.21:123 (2.debian.pool.ntp.org).
Jun  9 12:42:47 raspberrypi pulseaudio[625]: E: [alsa-sink-bcm2835 Headphones] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually not$
Jun  9 12:42:47 raspberrypi pulseaudio[625]: E: [alsa-sink-bcm2835 Headphones] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_bcm2835'. Please report t$
Jun  9 12:42:47 raspberrypi pulseaudio[625]: E: [alsa-sink-bcm2835 Headphones] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() r$
Jun  9 12:43:19 raspberrypi lw.comm-server[354]: INFO: Connecting to USB,/dev/ttyACM0,115200
Jun  9 12:43:19 raspberrypi lw.comm-server[354]: INFO: Connected to /dev/ttyACM0 at 115200
Jun  9 12:43:22 raspberrypi lw.comm-server[354]: Marlin detected (RE_NA)
Jun  9 12:43:25 raspberrypi lw.comm-server[354]: laserTest: Power 50, Duration 20, maxS 255
un  9 12:43:22 raspberrypi lw.comm-server[354]: Marlin detected (RE_NA)
Jun  9 12:43:25 raspberrypi lw.comm-server[354]: laserTest: Power 50, Duration 20, maxS 255
un  9 12:43:22 raspberrypi lw.comm-server[354]: Marlin detected (RE_NA)
Jun  9 12:43:25 raspberrypi lw.comm-server[354]: laserTest: Power 50, Duration 20, maxS 255
  1. Also checked the running logs and there also doens’t seem to be an issue there.

A snippet from the journalctl - f is attached:

-- Logs begin at Wed 2021-06-09 12:41:36 BST. --
Jun 09 12:51:38 raspberrypi lw.comm-server[354]: Run Command (M5)
Jun 09 12:51:58 raspberrypi lw.comm-server[354]: laserTest: Power 50, Duration 20, maxS 255
Jun 09 12:53:18 raspberrypi sshd[938]: pam_unix(sshd:session): session closed for user pi
Jun 09 12:53:18 raspberrypi systemd[1]: session-4.scope: Succeeded.
Jun 09 12:53:18 raspberrypi systemd-logind[343]: Session 4 logged out. Waiting for processes to exit.
Jun 09 12:53:18 raspberrypi systemd-logind[343]: Removed session 4.
Jun 09 12:53:36 raspberrypi sshd[1860]: Accepted password for pi from 192.168.1.64 port 59397 ssh2
Jun 09 12:53:36 raspberrypi sshd[1860]: pam_unix(sshd:session): session opened for user pi by (uid=0)
Jun 09 12:53:36 raspberrypi systemd-logind[343]: New session 5 of user pi.
Jun 09 12:53:36 raspberrypi systemd[1]: Started Session 5 of user pi.

The M5 command I ran showd up as well as the laser test command (the laser test command showed up consistently in the syslog as well. I tried manually running the laser with M3 SXXX again to double-check and it worked.

Thanks for any guidance!

Sidenote: I noticed that when running a jog command the Gcode was added to queue but the same cannot be said for the laser test. Is that a valid concern?

Jun 09 12:57:41 raspberrypi lw.comm-server[354]: Jog X,100,1500
Jun 09 12:57:41 raspberrypi lw.comm-server[354]: Adding jog commands to queue. blocked=false, paused=false, Q=0
Jun 09 12:57:56 raspberrypi lw.comm-server[354]: laserTest: Power 50, Duration 20, maxS 255

Thanks once again and sorry if I am missing something dreadfully obvious I am truly a noob at Rasppi and Linux.

Dont worry about the differences you se in the logging, they are just differences in the wording used by the comm-server when logging.

The marlin version detection looks suspicious. What do you see on the serial port itself when the firmware boots up?

Hi,

I see the following on the laser web exe frontend when I boot it up.

Serial Port
Marlin Version

I’ve managed to fix the RE_NA problem on the Marlin version through updating the Version.h file. Sadly, the laser test function still doesn’t work as expected. However for the time being I have worked around it by adding a macro which does the same thing through M3, G4 and M5 GCODE. I guess that will do. My bigger issue now is fixing the quality of my jobs but I will open another thread for that. I think the original question has already been solved as it is possible to run lw-server on a buster 3B+ but I will still be buying a 3B to load Jessie so that I can test to see if these problems are caused by the distro.

Cheers and thanks so much for the help everyone has provided so far!
Ethan

1 Like