Sean Meighan
Software => Bugs in xLights/Nutcracker => Topic started by: reelpilot on April 27, 2018, 10:19:59 AM
-
I've come across what appears to be an error when uploading xlights configuration to a Falcon controller on the output side. In my example I created a 32 strand mega tree with 50 pixels per strand. I divided those 1600 pixels into 8 strings of 200 pixels, so the xlights mega tree config is 8 strings, 200 nodes and 4 strands/string. The controller connection is set to port 1. If I upload the output to my F16 it configures properly showing the first 8 outputs on the F16 as 200 pixels each.
The problem arises if I add a star (or other model) to that setup for a tree topper. The star is set to connect after the last pixel of the mega tree, so I add the default 50 pixel star with a start channel set at the end of the mega tree and a controller connection to port 1 and upload that output configuration to the F16. On the F16 it shows port 1 with 680 pixels (should be 200) and the rest are all 200 (port 8 should be 250). So it seems that adding a model that connects to the end of a mega tree that spans multiple ports introduces an output uploading problem.
-
I've come across what appears to be an error when uploading xlights configuration to a Falcon controller on the output side. In my example I created a 32 strand mega tree with 50 pixels per strand. I divided those 1600 pixels into 8 strings of 200 pixels, so the xlights mega tree config is 8 strings, 200 nodes and 4 strands/string. The controller connection is set to port 1. If I upload the output to my F16 it configures properly showing the first 8 outputs on the F16 as 200 pixels each.
The problem arises if I add a star (or other model) to that setup for a tree topper. The star is set to connect after the last pixel of the mega tree, so I add the default 50 pixel star with a start channel set at the end of the mega tree and a controller connection to port 1 and upload that output configuration to the F16. On the F16 it shows port 1 with 680 pixels (should be 200) and the rest are all 200 (port 8 should be 250). So it seems that adding a model that connects to the end of a mega tree that spans multiple ports introduces an output uploading problem.
Sounds like it did what you told it to do. Not sure if it will fix it but shouldn't the spot I highlighted be assigned to port 8?
-
Sounds like it did what you told it to do. Not sure if it will fix it but shouldn't the spot I highlighted be assigned to port 8?
My understanding in this scenario is that the star is still set to port 1 even though in actuality it is plugged into port 8. This is because the star is chained to the end of the mega tree and the mega tree is set on port 1. I believe Keith talks about this in one of his videos. xLights knows the mega tree in this example takes up ports 1-8 and automatically divides up the channels to each of the ports, so adding the star to the end of the mega tree should follow the same logic. In fact if I were to assign the star to port 8, I receive an error message saying that this port already has a model on it. This supports the logic that the star should be assigned to port 1.
-
Do like I do and put every model on it's own port. Otherwise I'm afraid you'll have to let Keith weigh in on this.
-
This is a case the upload does not support right now. You can only daisy chain models on the same output for upload if all the models are solely on that one output.
In theory I can add this but the logic is mind bending stuff that I have not yet got my head around.
Sent from my iPhone using Tapatalk
-
Thanks for the input Keith. I was under the impression that you could daisy chain models across outputs so I was wondering why it wasn't working. It's not a big deal since it only takes a minute to manually make the correction.
-
Thanks for the input Keith. I was under the impression that you could daisy chain models across outputs so I was wondering why it wasn't working. It's not a big deal since it only takes a minute to manually make the correction.
Like I say I think I could work it out. It’s just not something I have spent time on. There are a bunch of these rules around the controller upload.
Sent from my iPhone using Tapatalk
-
There is one other thing I encountered last year and it still appears to be present. I have 6 FPP's in my display that I use the FPP connect to upload the configuration. When I use FPP connect and send the configuration to the individual Pi's, the E131 channel outputs on the FPPs show every universe across all 6 Pi's and they are all checked as active. Only the universes locally associated with that specific Pi need to be active and having them all active grinds the network to a halt, even with unicast. So last year after FPP connect uploaded my 130 total universes to all my FPPs as active, it was necessary to go back into each Pi and uncheck all the universes that were not local to that Pi.
-
Not true. You should have just turned off e131. One checkbox on each pi. In fact I don’t think you even needed to upload it at all.
Sent from my iPhone using Tapatalk
-
Not true. You should have just turned off e131. One checkbox on each pi. In fact I don’t think you even needed to upload it at all.
I'm using the Pi as a show player so I need e131 enabled to be outputting to lights. The upload would be necessary to define the universes and ip addresses for the various controllers. Am I missing something here? I thought this was the basic setup for using FPP as a show player and I've been using this setup for years trouble free. The only issue came this past year with the new FPP connect feature which was sending and enabling e131 outputs for all Pi's.
-
Sounds like this feature is not for you. Just set your stuff up manually. Most people only use one FPP and that's what the feature is designed to work with.
-
If you are uploading to multiple pi’s aren’t you using them as remotes and pulling data from the fseq file on. Each. In that case you don’t need to upload the config.
Sent from my iPhone using Tapatalk
-
If you have each pi sending data out to a subset of controllers then yes this isn’t designed for you.
Sent from my iPhone using Tapatalk
-
I'm just trying to figure out what FPP connect can or cannot do and how that relates to my display. I presume my setup is typical to that of most people who utilize the master / remote(s) feature with pi's where each remote is paired with one controller. If this goes beyond the scope of what this feature was meant for, then I apologize for this back and forth. I just haven't come across anything from the xlights videos, both from the Vegas seminar or posted to the site, that mention this was not possible.
If you are uploading to multiple pi’s aren’t you using them as remotes and pulling data from the fseq file on. Each. In that case you don’t need to upload the config.
The pi's are used as remotes and only have the fseq file on them. How would the remote pi's know what to listen to if the universe range and FPP start channels aren't defined in each remote's e131 channel outputs tab? If I get rid of that data the remotes just stop working.
-
Your configuration is not one fpp connect was created for. How would we know which universes to enable on each pi.
Sent from my iPhone using Tapatalk
-
Thanks for clarifying.
I would think the possibility is there for xlights to know which universes to send if FPP connect worked similar to the upload to controller feature. Hypothetically the user could from the setup tab select the block of universes that are associated with each pi and then have FPP connect only send the data for the highlighted universes. If no universes are highlighted then the entire universe data would be sent.
-
Don't make this so complicated. I use 10 remote Pis and each is configured for the full 64000 channels of my configuration. Is that the efficient way to do, probably not, but so what, it works. And it is simple to configure. It is the controllers that will sort out what they need and not the Pis.
-
Yeah I'm not sure I follow how you have things setup but I assume all these Pis are not sending out onto the same network or else there would be no need for the additional Pis. You stated you have universes "local to each Pi". How exactly is that wired?
-
I think Gil he has his pi’s connected to each other over wifi then a wired connection to one or two controllers.
So he uses sync over wifi to control them and they then pump out the data over the wire to the controller.
I don’t see any easy way to support this configuration for channel configuration upload. His suggestion above seems awkward. If you can’t make it remember the configuration you may as well manually configure it.
And once the wifi remote functionality in the v3 falcons comes along there will be even less need for this.
Jim solution will work until the universe count gets up to a 100 or so.
Sent from my iPhone using Tapatalk
-
Yeah but the local E1.31 traffic on a remote Pi doesn't try to go back out the wifi right?
-
Keith pretty much summed up how my setup works. The pi's are wirelessly on the same network and each has a wired connection to one controller. Sync packets travel over the common wifi network via master / remote and plays the show. I would think this is typical of anyone using master and remotes.
Last year I originally had my configuration for the full channel count as Jim suggested, but it slowed the show network to a standstill. When I attempted to play a 4 minute sequence it literally took over an hour to play out. It was moving just a few frames at a time and would completely lock up frequently.
I certainly don't mind manually configuring my pi's, but if there was a way to incorporate it into xlights I think it would benefit those who use master and remotes with high channel counts.
-
Yeah that slowness is a problem on the pi’s with unicast.
Sent from my iPhone using Tapatalk
-
Yeah it must be limitations with the Pi. We had the guys from the Illuminationz display in Arizona run over 1000 universes from a single PC.
-
The fix for pi slowness is to add static arp entries for the nonexistent controllers.
Sent from my iPhone using Tapatalk