Issue Daisy Chaining RP32s

M

morbiddk

New member
I'm looking to add a second Renard Plus 32 to my setup to make things easier to run. My first RP32 works just fine, but daisy chaining the second isn't working as expected. When I run my test chase sequence in FPP both RPs are pushing the same channels out the same ports rather than the second using 33-64.

My setup:
I'm using Vixen for sequencing and exporting to fseq that I am pushing to my FPP.
Vixen is setup with 1 Renard controller and 64 outputs.
I have re-patched my props to the channels in the order I want to use them.
My Test/Chase sequence runs through every prop in order for 2 seconds each.

I have a BBB running FPP 6.3.3 w/ a RS485 dongle. J1/RX on my first RP32 is connected to the dongle. J2/TX on that RP32 is connected to J1/RX on the second RP32.
I have reflashed the PIC18F4520s with the All-In-One firmware without any modifications. Not sure if I should try to use Start Addressing on the 2nd RP32, but I thought the way this is setup should work with the 1st RP32 taking the first 32 channels and the 2nd RP32 taking the next 32 channels.

Any assistance would be greatly appreciated.
 
So the issue is in your SW that generated the data. As for the Renards, the only time you set start address is when you are using a broadcast media to distribute the data. You are using a serial media. The reason I wanted to see the FPP config was to make sure you had a single 64 channel block going out.

Renard is a consumptive protocol. That means each PIC strips the first byte of data that it sees on the data line and forwards the rest. If the data is duplicated, then it is happening at the point at which the data is being generated.
 
I'm just not seeing where or how this might be duplicated from the software side, assuming you mean Vixen. I have 1 Controller setup with 64 outputs. Only 36 outputs are patched currently. My test sequence only has 1, 2 second effect, for each element and each effect is in order of their output so I can trace where things are with my test SSR. What I see from the SSR is that when say Channel 1 is pushing data on the first RP32, its also pushing data on what should be Channel 33 on the second RP32.

I hope I'm explaining this well enough to understand.
 
I suspect vixen is doing the duplication. A look at the patching around channels 32 and 33 to see if 33 is patched to 1. I would also look at the sequence to see what is on the timeline.
 
This sounds like Ren #1 is not set up with default software but with start channel software. Therefore, it is passing all data to #2. I would reflash all controllers the way you intend to use them.
 
So I'm completely at a loss on this. Last night I rebuilt my Vixen profile, including the display layout and the sequence. I erased and flashed both PICs with a fresh download of the All In One firmware package. I even took the FPP out of the mix and have connected the first RP32 directly to my PC, but I'm still seeing the same issue.

I don't see any double patching in Vixen, didn't even know this was possible. The sequence is very simple, Element 1 which is Output 1 is light for 2 seconds, then Element 2 which is Output 2 is light for 2 seconds and so on, through all 36 Elements that I have, although they are not all patched 1-to-1 but all Elements are visibly only patched once.

I've added Vixen screenshots to hopefully hlep.
Screenshot 2023-11-21 091047.png
Screenshot 2023-11-21 091108.jpg
Screenshot 2023-11-21 091113.jpg
 
Oh my... after I posted the above I was wracking my brain on what this could be and thought, wait a minute lets double check the jumpers. For whatever reason my first RP32 had JP2 in Bypass mode, so of course it was passing the data over to the second RP32 without taking its addresses. Now I might have had a bad flash on the second RP32 PIC in that it was setup with Start Addressing, because when I flipped which RP32 was first at the very start of this, I had the same issue, and the jumpers on the second RP32 were as they should be.
What is it they say, KISS and its usually the most simple thing. With me that's how it seems to go.

One last little thing. Is there a different firmware for the PIC18F45K22, or something else I might have to do with the controllers? I have 2 of the PICs as spares, was going to use them as upgrades and never decided to use them, that I tried using during this troubleshooting and they didn't seem to work, status light never lit on either RP32. They seemed to erase and program fine with my PICKit3 and v3.10 software.
 
You must log in or register to reply here.
Back
Top