So I have been playing with my Raspberry Pi2 that I want to build a lighting control workstation for our theatre. And so far so good, it seems snappy enough. I am a big fan of the current paired down OS and dedicated QLC+ box approach. There are a few comments I would like to make:
1. The QLC+ for Raspberry Pi documentation and design is very much of the opinion that one should only run your workspace on it and not try design or too many other stuff. With the new Quad-Core faster processor is this still true? Can the design philosophy be relaxed/opened to account for this?
+ There is no possibility to communicate with a flash drive at the moment. What I would like to see is auto-mounting of usb disks and load and saving of workspaces in that. In a non-network environment this is especially needed.
+ It looks like one can only load your custom fixtures and the default workspace via the web interface. My box most likely will very seldom be connected.
+ When booting without a LAN connection there is a long wait timeout while the OS tries to connect with eth0. My usage will be mostly in a non-network environment with occasional connection to a network. I have not found any settings to connect (static or otherwise) when LAN is present and do nothing when it is not present, but I regard myself as linux baby. I will keep looking.
+ The look & feel is a little different, mainly due to the default background of the virtual console and UI components - it seems as if the controls on a settings box floats on top of the virtual console, without the bouandaries of the windows visble. Changing the virtual console background solves this.
+ The shutdown button is only visible in the web interface. Not a biggie as Massimo said he has not seen any issue with sudden power downs. It just makes me a little uncomfortable. I think there is a case for it on all OS's that has a software shutdown capability. When I hand over the console to an operator (even when it is a Lubuntu laptop) it would be great if there is a shutdown button that offers to save the current workspace and shuts down the app and computer. We are sticklers on protecting our equipment so everybody uses mantra of shutdown, switch-off and unplug. It would be fantastic if the lighting box could act the same.
+ When there is no default workspace specified then QLC+ is still started in run-mode. This is only a small irritation because one first has to turn off run-mode before you can play.
+ As mentioned in another thread (but repeated here for completeness), any local customisations like time zone, a real time clock, custom fixturesm is subject being wiped if you do an image based upgrade. If one had access to a flash USB one mitigate this with a few simple scripts in a file that one can run to re-instate all this.
I have also built QLC+ on the Raspbian but you get all the other stuff and currently one is limited to Qt4. I'll report back on that scenario later. I must also still test the various sound options.
All in all this is a great combination. My opinion at the moment is that it will be viable to build a lighting control box consisting of a large screen, RPi2 B+, wireless mouse & keyboard, small usb dmx interface and some custom joysticks & buttons. Once done, I'll post build details.
Raspberry Pi 2 B+ feedback.
-
Chris de Rock
to 1: on my Pi2 i can use QLC+ like on a standard pc.
to 4: just edit /etc/network/interfaces and remove the entry for eth0 or give eth0 a static adress.
to 4: just edit /etc/network/interfaces and remove the entry for eth0 or give eth0 a static adress.
-
Chris Laurie
Re 4: There is already a static address (192.168.0.252) that Massimo put in. The problem is that when there is no cable there is a timeout period before the boot continues. With a network it sails through it.
I may end up disable eth0 and then manually enabling it when I need connection but that is not ideal.
I may end up disable eth0 and then manually enabling it when I need connection but that is not ideal.
-
Chris de Rock
maybe its not the network that causes the timeout but a daemon. possible the ntp daemon?
-
Massimo Callegari
Wow Chris, this is indeed a rich report about the current status of the RPi port 
I'll try to reply to your points one by one
1. the quad core surely gives more breath and I'm quite sure the design area can be used quite smoothly now.
But please, consider 2 things:
* lot of users still have a RPi 1
* I would like to stick to a single image that runs on RPi 1 and RPi 2 so I cannot give the fact that there is a 4core CPU running QLC+.
Said that, building QLC+ on Qt4 is still valid and correct. Even the released .deb for desktop are based on Qt4 and not Qt5. The main difference is the multimedia part, which in any case is still under development/evaluation on the Raspberry.
In the RPi image I decided to go "the embedded" way, so opting not to have a X11 server with windows management. The advantage is a smaller footprint of the image and no overhead in graphics processing, so better performances since the RPi1 has not much to offer in that sense.
Unfortunately the downside is that there is no window manager, so when a window is open (e.g. dmx monitor) you can't close it if it doesn't have its own "OK" or "close" button.
Since 6 months I am following a few projects to eliminate this gap, but the technology I would like to use doesn't seem to be mature yet for the purpose.
I am referring to Qt+Wayland. In any case Debian Wheezy is becoming outdated.
The Debian team is working on Jessie, which apparently is just 70 issues away from being released. That means updated packages, new libraries (including Qt5), more up-to-date system. As soon as it is considered stable, I will switch to it and see if I can make RPi1 and RPi2 users happy either for performances and comfort
2. This has already been requested in this forum, so I guess it is time to consider its implementation
See this: https://sourceforge.net/p/qlcplus/discu ... /1d6191d1/
3. I'm afraid I can't help much on this. In the end you're not going to load custom fixtures every day, so when you need them, just connect your laptop with a cross ethernet cable and do it via web
4. See this: https://sourceforge.net/p/qlcplus/discu ... /7e7797a5/
rsyslogd is the one to blame. At the moment I haven't found a way to make it happy without an internet connection, so you need to disable its startup script.
The commmand is:
echo "manual" >> /etc/init/rsyslog.override
Documented here:
http://upstart.ubuntu.com/cookbook/#dis ... y-starting
I'll add this to the RPi user guide
5. It surely depends on how I built Qt on the RPi. The default theme is quite bad looking. I'll see if I can opt for a better one
6. I think you need to live with this at the moment, but I'll keep this in mind since most likely more and more users will want to do project design on the RPi itself
7. Didn't get this one. Can you please explain ?
8. Well, you have two options here:
* if you remember, in the past I released also some network packages. Lately I released mostly full images cause of the introduction of the RPi2, so to avoid confusion I preferred to go the "wipe" way.
I'll continue to provide network upgrade packages, so they won't override your custom settings
* keep in mind that the SD card can be read from your computer ! The partition where the system lies is formatted in Ext4, which is typical in Linux. So, if you have a Linux computer you can mount and modify it straight forward. On Windows and OSX you need to find some tools to read ext4 partitions.
For the extreme comfort, you can even create a script that, once the partition is mounted, will modify it in one shot.
So basically:
* flash a full image
* mount the ext4 partition
* launch the customization script
Takes like 3 minutes for everything
I'll try to reply to your points one by one
1. the quad core surely gives more breath and I'm quite sure the design area can be used quite smoothly now.
But please, consider 2 things:
* lot of users still have a RPi 1
* I would like to stick to a single image that runs on RPi 1 and RPi 2 so I cannot give the fact that there is a 4core CPU running QLC+.
Said that, building QLC+ on Qt4 is still valid and correct. Even the released .deb for desktop are based on Qt4 and not Qt5. The main difference is the multimedia part, which in any case is still under development/evaluation on the Raspberry.
In the RPi image I decided to go "the embedded" way, so opting not to have a X11 server with windows management. The advantage is a smaller footprint of the image and no overhead in graphics processing, so better performances since the RPi1 has not much to offer in that sense.
Unfortunately the downside is that there is no window manager, so when a window is open (e.g. dmx monitor) you can't close it if it doesn't have its own "OK" or "close" button.
Since 6 months I am following a few projects to eliminate this gap, but the technology I would like to use doesn't seem to be mature yet for the purpose.
I am referring to Qt+Wayland. In any case Debian Wheezy is becoming outdated.
The Debian team is working on Jessie, which apparently is just 70 issues away from being released. That means updated packages, new libraries (including Qt5), more up-to-date system. As soon as it is considered stable, I will switch to it and see if I can make RPi1 and RPi2 users happy either for performances and comfort
2. This has already been requested in this forum, so I guess it is time to consider its implementation
See this: https://sourceforge.net/p/qlcplus/discu ... /1d6191d1/
3. I'm afraid I can't help much on this. In the end you're not going to load custom fixtures every day, so when you need them, just connect your laptop with a cross ethernet cable and do it via web
4. See this: https://sourceforge.net/p/qlcplus/discu ... /7e7797a5/
rsyslogd is the one to blame. At the moment I haven't found a way to make it happy without an internet connection, so you need to disable its startup script.
The commmand is:
echo "manual" >> /etc/init/rsyslog.override
Documented here:
http://upstart.ubuntu.com/cookbook/#dis ... y-starting
I'll add this to the RPi user guide
5. It surely depends on how I built Qt on the RPi. The default theme is quite bad looking. I'll see if I can opt for a better one
6. I think you need to live with this at the moment, but I'll keep this in mind since most likely more and more users will want to do project design on the RPi itself
7. Didn't get this one. Can you please explain ?
8. Well, you have two options here:
* if you remember, in the past I released also some network packages. Lately I released mostly full images cause of the introduction of the RPi2, so to avoid confusion I preferred to go the "wipe" way.
I'll continue to provide network upgrade packages, so they won't override your custom settings
* keep in mind that the SD card can be read from your computer ! The partition where the system lies is formatted in Ext4, which is typical in Linux. So, if you have a Linux computer you can mount and modify it straight forward. On Windows and OSX you need to find some tools to read ext4 partitions.
For the extreme comfort, you can even create a script that, once the partition is mounted, will modify it in one shot.
So basically:
* flash a full image
* mount the ext4 partition
* launch the customization script
Takes like 3 minutes for everything
-
Chris Laurie
Thanks for the response Massimo!
I see Sourceforge forums have messed up the numbering of your response - it came out fine in the email notification.
Re #7 - Not a biggie, but I was wondering if no default workspace is defined could QLC+ not start in run mode or is that a given?
I see Sourceforge forums have messed up the numbering of your response - it came out fine in the email notification.
Re #7 - Not a biggie, but I was wondering if no default workspace is defined could QLC+ not start in run mode or is that a given?
-
Massimo Callegari
7) Basically the idea was to use the RPi headless, so everything would be done via web (so no design)
Keeping the operate mode always on would seem to be a "ready to play" solution
Keeping the operate mode always on would seem to be a "ready to play" solution
-
Chris Laurie
For the record the rsyslog.override trick did not work. I guess something else is starting the daemon.
-
Boxy
Hi guys,
Is there a hardware solution that can halt a Pi upon power-off (generic I know...)?
This would involve a large capacitor and voltage monitor that sends an interrupt to the Pi to halt upon a falling supply voltage. This would obviously require a small code module.
Our automotive ECUs don't need a shut-down command so it can be done.
For example, nobody shuts down their fixtures before turning off, and users will see the RPi as an extension of them. I could create a hardware design if S/W types gives me the timescales needed.
Cheers,
Boxy
Is there a hardware solution that can halt a Pi upon power-off (generic I know...)?
This would involve a large capacitor and voltage monitor that sends an interrupt to the Pi to halt upon a falling supply voltage. This would obviously require a small code module.
Our automotive ECUs don't need a shut-down command so it can be done.
For example, nobody shuts down their fixtures before turning off, and users will see the RPi as an extension of them. I could create a hardware design if S/W types gives me the timescales needed.
Cheers,
Boxy
-
Chris Laurie
@Boxy - I'm not sure I understand what you are saying. There are a few hardware solutions for auto shutdown of the Pi. These range form simple GPIO hacks (some with resistors). There are also a few add-on boards that does the whole power cycle shutdown thing.
From a software side it's a python or BASh script that polls the pins and initiates: sudo shutdown -h now
(or something like that).
From a software side it's a python or BASh script that polls the pins and initiates: sudo shutdown -h now
(or something like that).