no signal going to relays

Her is what I have and still not working any idea what I am doing wrong20230101_201714.jpg20230101_201745.jpg20230101_201756.jpg

Sent from my SM-N975U using Tapatalk
 
Check in 'device manager' on your PC in the serial devices section. This will confirm which com port the Arduino is actually on. You can plug/unplug it to see it pop up in the ports list. Beyond that as others have said, serial data is serial data. No changes needed to Arduino, the problem is therefore likely to be in your xLights config. You could use a program like WireShark to monitor what's actually being output to the port. I am not an xLights user but agree the output channels=1 looks suspicious.
 
Last edited:
I had it that way and still didn't work the Strang thing is when I connect the arduino seems like it's not connecting to xlights but when I click on the button on the sequence side that is the light bulb to see the lights working the arduinos little led starts flashing but ac lights don't don't do anything.

Sent from my SM-N975U using Tapatalk
 
Light blinking on Arduino means it's receiving data on the Serial port - so you have the COM port correct at least. Can you paste the sketch as text? It's tricky to follow from the screen photos.
 
Shore can the arduino works in vixen just retested it no problems just not working with xlights I think there my be a sketch problem that needs to be fixed to make it work with xlights or its something I'm doing wrong in xlights setup.

Sent from my SM-N975U using Tapatalk
 
Do you still have Vixen available? And you're saying this code still works with that?

Sorry I gave some mis-information earlier - WireShark can't monitor the serial port. But this can: https://www.eltima.com/products/serial-port-monitor/

Can you run both (Vixen then XLights) and compare what the 'packets' of data look like?

I assume the test sequence in the code runs ok in the setup function? From what I can see it should turn on all relays for 500ms, though you can configure the duration in the code.
 
mr fix said:
Shore can the arduino works in vixen just retested it no problems just not working with xlights I think there my be a sketch problem that needs to be fixed to make it work with xlights or its something I'm doing wrong in xlights setup.

Sent from my SM-N975U using Tapatalk
Click to expand...
Your problem is in the xLights configuration. There should be no differences in the sketch when you move from Vixen to xLights. I am not an xLights person so I cannot help with configuring it.
 
I was thinking the code was about the Urduino uno, but it's Spanish (maybe!)

uno == 126
dos == 33

is checking the value of bytes 1 and 2 in the serial data
126 is '~' and 33 is '!'

Hang on...... In your XLights setup you have PREFIX = '~' (first byte), and POSTFIX = '!' (last byte)
The Arduino code is expecting prefix = '~!', no postfix???

Again the serial data monitor should show point at this problem

I would also strongly advised against this line checking
Serial.available() >= (CHANNEL_COUNT+2)
As you don't need to have all data in the 'buffer' to start processing the bytes. There is also no guarantee that you have a whole 'frame' of data in the buffer, staring at the correct position.
 
Last edited:
There are lots of other issues in that code besides the ones you pointed out. Best to leave it alone or now and solve one issue at a time. Yes the alignment sequence characters ~! both should be in the prefix field.
 
Agree - I have rewritten as this, may not be perfect but hopefully improved. Also untested. It doesn't have the watchdog and test functions.

Code: 
//this section maps channels to pins 
#define CH01 2
#define CH02 3
#define CH03 4
#define CH04 5
#define CH05 6
#define CH06 7
#define CH07 8
#define CH08 9
#define CH09 10
#define CH10 11
#define CH11 12
#define CH12 13
#define CH13 A0
#define CH14 A1
#define CH15 A2
#define CH16 A3
#define CH17 A4
#define CH18 A5
#define CH19 A6
#define CH20 A7
#define CH21 A8
#define CH22 A9
#define CH23 A10
#define CH24 A11
#define CH25 A12
#define CH26 A13
#define CH27 A14
#define CH28 A15
#define CH29 22
#define CH30 23
#define CH31 24
#define CH32 25
#define CH33 26
#define CH34 27
#define CH35 28
#define CH36 29
#define CH37 30
#define CH38 31
#define CH39 32
#define CH40 33
#define CH41 34
#define CH42 35
#define CH43 36
#define CH44 37
#define CH45 38
#define CH46 39
#define CH47 40
#define CH48 41

#define channelCount 48

byte channels[] = {CH01,CH02,CH03,CH04,CH05 ,CH06,CH07,CH08,CH09,CH10,CH11,CH12,CH13,CH14,CH15,CH16,CH17,CH18,CH19,CH20,CH21,CH22,CH23,CH24,CH25,CH26,CH27,CH28,CH29,CH30,CH31,CH32,CH33,CH34,CH35,CH36,CH37,CH38,CH39,CH40,CH41,CH42,CH43,CH44,CH45,CH46,CH47,CH48};

void setup() {

  //initialise the output pins you're using
  for (byte i=0; i < channelCount; i++){
    pinMode(channels[i], OUTPUT);
    digitalWrite(channels[i],LOW);
  }

  //start the serial port
  sei();
  Serial.begin(57600);
}

void loop() {

  while(true){//you need this for the 2 x continue statements to exit to
    
    while(!Serial.available()); //pause if no new serial data
    
    if(Serial.read() != '~') {
      continue;  //exit while loop if character is not 1st byte of header
    }

    while(!Serial.available()); //pause if no new serial data
    
    if(Serial.read() != '!') {
      continue; //exit while loop if character is not 2nd byte of header
    }
    
    for(byte i=0; i<channelCount; i++){
        
        while(!Serial.available()); //pause if no new serial data
        
        byte channelValue = Serial.read(); //read the next available byte from the serial buffer

        //now turn the pin associated with the current channel on/off depending.....
        if(channelValue < 127){
          digitalWrite(channels[i],LOW);
        }else{
          digitalWrite(channels[i],HIGH);
        }
    }       
  
  }//end of main 'while' loop

}

It may also be preferable to store all the 'read' values, then do the digitalWrite operation in a separate loop in the interests of speed.
 
Last edited:
Looks good I will put this sketch on another arduino I have .
I did figure out the problem with the help of the zoom team on xlights they are great
1 The sketch was good and not the problem
2 it was the setup I had in xlights was the problem I had to change it to DMX and changed the channels and controller order and it worked.

Sent from my SM-N975U using Tapatalk
 
Thanks for confirming.

I made a small change to the code I posted - the 'continue' statements need to be inside a loop structure (inside the outer 'loop' function). This should work, though is untested. I have used a while() function though there are other ways of doing this too.
 
Last edited:
No didnt change a thing the sketch i used it was the one i used with vixen in the past.
I posted the sketch before in this post, i didn't Wright the sketch i think the only thing I did was in the sketch were it was saying vixen I changed it to xlights but I don't think that would make a difference and at the end were it says random sequence were it says high and low I changed to low low to turn light off and or high high for the lights to stay on the random sequence drives me nuts.
 
Last edited:
XLights_COM_SPEED is a named constant (using #define ....) for the serial port baud rate so you can call it whatever you want. XLights (or Vixen) means nothing in this context. Changing both the output states does to LOW will indeed stop the random mode, though you could actually remove this whole section and save some processing time (every digitalWrite statement uses a number of clock cycles). The way the code needs to 'reset itself' if there's an issue points to bad design - but if it works for you then by all means stick with it. Also in the alternative sample I sent I removed all the 'inverted' logic - but if it's the wrong way round then just change the HIGHs to LOWs in the digitalWrite statements. I assumed LOW= AC lights off and High = AC lights on.
 
RichieNorthcott said:
XLights_COM_SPEED is a named constant (using #define ....) for the serial port baud rate so you can call it whatever you want. XLights (or Vixen) means nothing in this context. Changing both the output states does to LOW will indeed stop the random mode, though you could actually remove this whole section and save some processing time (every digitalWrite statement uses a number of clock cycles). The way the code needs to 'reset itself' if there's an issue points to bad design - but if it works for you then by all means stick with it. Also in the alternative sample I sent I removed all the 'inverted' logic - but if it's the wrong way round then just change the HIGHs to LOWs in the digitalWrite statements. I assumed LOW= AC lights off and High = AC lights on.
Click to expand...
Yes
high =ac light on
Low = ac light off

I haven't got around to it yet but I will try the sketch you sent to see how it works and I will let you know

Sent from my SM-N975U using Tapatalk
 
You must log in or register to reply here.
Back
Top