Sean Meighan
Welcome => Do You Need Help? Post it here => Topic started by: Gary on October 10, 2017, 03:13:13 AM
-
After accidentally pressing Ctrl-R in Chrome instead of Shift-R typing up this message and losing all my work, I'm retyping this in somewhat abbreviated form... >:(
After some months off of this hobby, I upgraded from FPP 2016.51 to 2017.30 64-bit.
I'm adding a MegaTree this year and while fiddling around with some effects, I noticed that when the screen showed Green, my sample pixel string hooked up to my controller was Red. Similarly, Blue on-screen lit up my pixels Green, and Red on-screen lit up my pixels Blue.
My megatree's start channel is 8193 for Red, 8194 for Green, and 8195 for Blue. Checking in FPP's test mode and turning on the individual channels, the colours work out okay.
Checking out xLights test mode, I found out that in order to turn on the first pixel of the tree, I need to turn on 8509 (xLights labels it as supposed to be Green, but my pixel glows red), 8510 (Blue turns Green), and 8511 (Red turns Blue).
I was scratching my head on the channel shift, and then realized that I have a USB DMX dongle in my Setup tab that had 316 channels reserved for it (yeah, it's a weird number), and 316 is the difference between 8509 and 8193. Well, when I delete the DMX dongle from the Setup tab, my pixels display the correct colour. However, I need to keep my DMX dongle for my show.
Is this a bug that was introduced since 2016.51?
-
Divide by 3 - you'll see that 316 is not a multiple, therefore it is throwing off your count. Change it to 315 or 318 and try.
-
Divide by 3 - you'll see that 316 is not a multiple, therefore it is throwing off your count. Change it to 315 or 318 and try.
Yes, that sort of explains the issue of the Red, Green, and Blue being out of sync, but it doesn't solve why my channels are off by 316.
-
You should show screenshots of the Megatree model properties, the setup tab, and how the related E1.31 and strings are setup on the FPP. Plus restart xLights before using the Test tab after changes. I never use the test tab I just create a dummy animation sequence and drop and effect on a model to test it so that eliminates any possibility of test tab errors.
-
I will do that when I get home tonight.
-
It sounds to me like your models are mapped to channel 1 instead of being tied to the first channel of your first e131 universe. Have you run check sequence?
-
Oh ... and upgrade to .32
-
Gil, here are my screenshots. I upgraded to 2017.32 before doing these screenshots.
-
It sounds to me like your models are mapped to channel 1 instead of being tied to the first channel of your first e131 universe. Have you run check sequence?
My lowest DMX channel number is 257 (I reserved 1 through 256 for something else in the future)
My lowest Pixelnet channel number is my Small Zigzag tree at channel 317.
Running Check Sequence doesn't bring up anything of significance other than reminders of dead channel ranges and warnings about some models I made without a controller configured because I'm still working on that... I was hoping to use the Generate Custom model feature once I get these issues with my channel mappings figured out.
-
I've never seen that F16v1 controller software before. From everything you show my guess is that software has no idea that you have the first 316 channels assigned to a different type of output. Where in that software do you tell it that Universe 1 starts at 317. I bet that software believe universe 1 starts at 1.
-
I've never seen that F16v1 controller software before. From everything you show my guess is that software has no idea that you have the first 316 channels assigned to a different type of output. Where in that software do you tell it that Universe 1 starts at 317. I bet that software believe universe 1 starts at 1.
The Falcon Controller software does seem to be working properly because I was able to program the channel range for each output on my controller. I know this because when I use the FPP Test mode (i.e. xLights not in the equation) and type in channel range from 8193 to 8193, I get a red pixel for the first strand on my mega tree as I would expect.
Is it possible to set up xLights so DMX stays where it is from channels 1 through 316 and have E131 start at channel 1 as well? If I have my Pixelnet controllers configured to "listen" starting on channel 317, channels 1 through 316 would be "ignored" by them, correct?
-
I suggested you create an animation sequence and drop an effect on the tree and see what happens instead of using Test mode. It doesn't sound like you tried that. That's the only way to rule out whether its a problem in the Test tab.
-
I suggested you create an animation sequence and drop an effect on the tree and see what happens instead of using Test mode. It doesn't sound like you tried that. That's the only way to rule out whether its a problem in the Test tab.
I did. In my message with the bunch of screenshots, refer to the image called xLights Sequence Test Effect Purposely on Wrong Channel (Turns First Pixel of Actual String 1 Red).png
Rather than being an "exciting" effect lighting up the whole tree, I chose to turn on one pixel. The 6th pixel on the third strand (1 and 2 are a zigzag of 50 pixels each totaling 100 pixels on one controller port) on-screen lights up green (you may need to squint). In the "real world", the first pixel on my first strand lights up red.
Note that I've also attached a screen print of xLights I have installed at work. I installed it there a while back to fiddle around with it on my lunch breaks. While the version isn't 2016.51 what I originally had at home (work has 2016.56), you can see how my Setup tab was configured in the past and output to my controllers worked properly. I don't think I ever fiddled around with the Setup tab at work after copying my config from home since I never had a controller at work to output to.
-
The real world picture sure looks green to me.
-
The real world picture sure looks green to me.
That's the on-screen preview window where it's green.
If I brought out my digital camera and snapped a photo of the "real world" and posted it here, the physical pixel (pixel 1 of strand 1) connected to my controller would be glowing red. I could do that, but I can already be accused of attachment overload.
-
In my pixelnet world I have have the 1st 512 channels reserved for DMX although I have slowly reduced my DMX channels to a couple in the 17x range. My controller and network start at channel 1, but model starts at 17x My pixels start at 513. For my network I just have 64 universes of 512. Not sure I understand what your problems really are.
-
Maybe try changing output 1 to be an E1.31 output set to a bogus universe like 99. Then see if it works. If so then I think that would prove xLights is not properly handling that DMX output type.
-
Maybe try changing output 1 to be an E1.31 output set to a bogus universe like 99. Then see if it works. If so then I think that would prove xLights is not properly handling that DMX output type.
You mean like in my "DMX to Bottom" image where I shoved it to the bottom?
If so, my pixels behave as expected both on-screen and in the real world.
Either way, I can't keep my DMX stuff in that channel range because, well, it doesn't support such high channel numbers. :)
-
As an experiment, I thought that I'd try taking all my current "live/production" xLights 2017.30-related files, place them into a separate folder, and then restore my backed up xLights 2016.51-related files to my "live/production" folder and open xLights 2016.51 again (I still had it installed in my Program Files (x86) folder) to see how it behaves.
I expected the FPP Testing, xLights Testing, a sample xLights Sequence, and the "real world" pixels to match up, but they didn't, either. What's weirder is that in 2017.30/32, my channels were shifted by 316 (the number of channels I had set aside for DMX), but in 2016.51, my channels were shifted by 512 (an entire DMX universe).
Scratching my head on how my xLights channels were off in 2016 as well, I tried making an FSEQ file out of my test sequence, uploaded it to my FPP and ran it there. The channels worked as I wanted.
Thinking about this more, when I really dove into xLights in 2016, I don't think I had the USB DMX dongle in my Setup tab initially. I initially did a bit of dabbling with xLights running my sequences by sending data to my F16-B running FPP in Bridge mode, but between pixels being out of sync with my music and stuttering due to presumably WiFi lag time (along with Bridge Mode randomly locking up my F16-B), I decided to keep my F16-B in Player (Standalone) mode and rely on my on-screen previews to see what pixels will be lighting up and use FSEQ files to run my show. I also barely used the Test mode in xLights back in 2016.
I still can't explain why the channels were off by 512 in 2016.51 vs. 316 in 2017.30/32, but I won't worry about it now and just stick to using FSEQ files. I've attached a screenshot of my Setup tab in 2016.51... the only difference is that the Baud Rate shows as N/A vs 250000 in 2017.30/32.
In the end, is this entire issue with channels being out of sync if a USB DMX dongle is configured to have its channels before any E131 considered a bug which will be fixed?
-
You realize that if an FSEQ file exists then we use the number of channels defined in that file instead of what you have in setup? I'm not sure I can trust any of your experiments because it doesn't sound like you realized that when you change the setup you really need to delete the FSEQ files, reopen xLights, and recreate them or things may be invalid.
-
I wasn't using FSEQ files for any of my experiments until the end. Before that, it was all xLights communicating directly with the controller.
-
An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not. You must delete the fseq while the sequence is closed. The fseq will be rebuilt the next time you open the sequence and save it.
-
At some point you'll need to get in TeamViewer with others since just talking about it amongst us is not fixing the problem.
-
An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not. You must delete the fseq while the sequence is closed. The fseq will be rebuilt the next time you open the sequence and save it.
What if I have xLights set to Render on Save? Doesn't that create/overwrite the FSEQ file without needing to close out of the sequence and re-open it?
-
At some point you'll need to get in TeamViewer with others since just talking about it amongst us is not fixing the problem.
Since I have an explanation and workaround by continuing to use FSEQ files in FPP like I did in 2016, I'm happy to work with that in 2017.
That said, I'm willing to have someone to try to work through the issue with a TeamViewer session together. If I don't have any volunteers, perhaps someone can try to reproduce the problem on their setup by adding a dummy USB DMX device (with a few hundred channels assigned) above their E131 stuff and see what happens with their on-screen preview vs. "real world" channel "alignments" when they control their pixels directly from xLights (rather than FPP)?
-
An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not. You must delete the fseq while the sequence is closed. The fseq will be rebuilt the next time you open the sequence and save it.
What if I have xLights set to Render on Save? Doesn't that create/overwrite the FSEQ file without needing to close out of the sequence and re-open it?
Render on save just updates the old fseq, it does not create a new one. We have told you multiple times to delete the old fseq. You have now spent more time arguing against doing that than just doing it.
-
An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not. You must delete the fseq while the sequence is closed. The fseq will be rebuilt the next time you open the sequence and save it.
What if I have xLights set to Render on Save? Doesn't that create/overwrite the FSEQ file without needing to close out of the sequence and re-open it?
Yep Jim is right. Yes it does overwrite the FSEQ but with possibly the WRONG channel count due to what I've been saying. Glad you're happy to do it your way. See ya next year.
-
Note that I'm back to using xLights 2017.32 64-bit for this response...
I would have thought that overwriting an FSEQ file is the same thing as creating a new one. I'm not trying to be difficult and not listen to others peoples' advice.
Okay, rather than using a workaround, I'm curious to see if I CAN get this to work... I closed out of xLights, deleted the FSEQ file associated with the Test Sequence XML file, opened my Test XML and saved it to re-render a new FSEQ file.
Now, to light up my megatree's first strand's first physical pixel is channel 9021 (the Red portion of RGB), which calculates to Channel 8193 (what's assigned to the controller's port 1 for that strand) + 512 (one universe) + 316 (my first Pixelnet channel) = 9021. ??? Going into the xLights Test window behaves the same way. Does the Test window use a FSEQ file in some way that I need to clear out?
I'm sorry to be causing everybody so much aggravation here and instead of trying everything suggested. I'm on a time crunch here as my pre-sale lights came mid-September rather than the scheduled May/June. Since I can usually only deal with Christmas stuff in the evenings after the kids are asleep and I live on the West Coast (which means that many others are asleep while I'm still up), I'm typing up any responses that I feel would be relevant during the day while I'm at work and away from my light equipment. In fact, I'm typing this just before going to work this morning. I'm not purposely arguing/refusing to take peoples' helpful advice.
-
I don't know if the FSEQ has anything to do with it. If you just open xLights and go straight to the Test tab then there is no FSEQ in the mix at all. I was just trying to clarify that it is possible for it to cause a problem. The issue is I believe we still have scenarios where you can change the Setup and the channel buffers do not get deleted and recreated with the new size. Same problem used to exist with changing a sequence duration but I fixed that one. xLights was designed so that if an FSEQ exists then we use it to define the number of channels for the channel buffers so an existing FSEQ overrides what you have in setup. It was done that way so that you could open an FSEQ and play it. It's probably nothing to do with your issue. I thought I would mention it, you would try it, and we would move on but it took forever to get to that point.
At this point only thing I can do is wait till I'm putting up some lights and then try throwing a DMX output at the front and see if it causes a problem.
-
We are in zoom Friday night your time. Why don't you pop in and ask your questions. See xlights.org for the link.
-
Sorry, I didn't get the message until Saturday morning. Either way, I had stuff going on Friday until 10:30 PM or so.
However, this upcoming weekend the rest of my family will be away, so it's all going to be all about Christmas! I didn't see any obvious schedule on the web site... nothing in the Calendar, Events/Gathering, etc.
Is it a set schedule every Friday night?
-
For the US the set schedule is 7p eastern time every Wed
For Australia it is Friday
For adhoc the zoom session is open 24/7 and other folks can often be found in there or you can schedule a time with a mentor.
-
7 PM Eastern doesn't work for me because... well, I'm still at work.
That time and time zone in Australia on Fridays?
-
The Wednesday night and Friday night calls go for a minimum 5 hours. Surely you can find 10 minutes out of your busy schedule if it is important to you.
-
7pm Sydney time ... finishing usually just after midnight. It can be a slow start and a quiet finish so if no one is on just hang until they are or ping the chat on Acl and invite folks to join you.
-
Isn’t there an option somewhere that deletes the fseq file on render(erase/canvas I think it says)?
Sent from my iPhone using Tapatalk
-
The Wednesday night and Friday night calls go for a minimum 5 hours. Surely you can find 10 minutes out of your busy schedule if it is important to you.
Oh, it's 5 hours long... I should be able to make it to that. :)
-
7pm Sydney time ... finishing usually just after midnight. It can be a slow start and a quiet finish so if no one is on just hang until they are or ping the chat on Acl and invite folks to join you.
I Googled "7pm sydney time in vancouver" and I'd rather avoid that unless I'm really desperate. Well, I'll see how late I stay up tonight, LOL!
-
So do Wednesday 7pm till 2am New York time.
-
So do Wednesday 7pm till 2am New York time.
If you can see this, I'm connected and waiting at for 1 AM my time...
-
Thanks for your help on the Zoom Meeting, Keith.
To document the solution for others to see, I've attached a screen print with my channels for each universe jogged up by 316 in FPP.