DiyLightAnimation

Software => Light Show Pro => Topic started by: wftxlites on June 04, 2011,

Title: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 04, 2011,
I have built a DMX std. sequence in LSP and then added a Smart String/Pixelnet controllers. I then exported to .oms (optimised scheduler file). The problem is with com port settings. I am under the impression that pixelnet can run on the same dongle as DMX, but maybe it needs to be a separate dongle. In any event I set both to the same com port in the scheduler, but when the sequence starts to play it complains about the setting for pixelnet com port.

Does anyone have a clue what I need to do? I do not have any way to test this beyond software at this point until the SS H/W is built.

Thanks for any input,

Greg

P.S. Ver. 1.8 LSP tried last two revs and no difference.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: mmulvenna on June 04, 2011,
You are not allowed to view links. Register or Login
I have built a DMX std. sequence in LSP and then added a Smart String/Pixelnet controllers. I then exported to .oms (optimised scheduler file). The problem is with com port settings. I am under the impression that pixelnet can run on the same dongle as DMX, but maybe it needs to be a separate dongle. In any event I set both to the same com port in the scheduler, but when the sequence starts to play it complains about the setting for pixelnet com port.

Does anyone have a clue what I need to do? I do not have any way to test this beyond software at this point until the SS H/W is built.

Thanks for any input,

Greg

P.S. Ver. 1.8 LSP tried last two revs and no difference.

Hi Greg,

What error are you getting?
What com port(s) are you using? Must be below "10" in v1 (corrected in v2 when it is released).
What dongle are you using?
BTW, you can just use the hardware test function in the sequencer to test the hardware without having to build a sequence and generate files for the scheduler.

Hope that helps some
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: RJ on June 04, 2011,
Since my info is limited on your issues let me say some high level stuff that reading you post made me think.

Pixel can run on the Lynx DMX dongle if it is flashed with the firmware for PixelNet but it can only do one, DMX or Pixelnet.

You can not use the DMX and the PixelNet plugin pointing at the same dongle if this what I am understanding.

You can run two dongles one DMX firmware and one with PixelNet firmware on different com ports and set them up.

But the real way to do it is only use PixelNet and get the DMX output out of the hubs DMX output. This lets you use one plugin(less issues) and still run both protocols. Thats why I put the DMX output on the hub.

RJ
 

Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 04, 2011,
I am using Lynx Dongles V2.

This is the error.

There was an error Connecting to the Pixelnet/Smartstring
output for zone 1
----------------------------
Unable to open Com 4
---------------------------
Please correct the output configeration error or
reset the output device

I was not aware it was possible to test the hardware using the sequencer.  I will
use two dongles one with DMX firmware and One With Pixelnet firmware. I will redo
my testing and see if it solves the problem.

Ok, from what I am understanding use a DMX firmware configered dongle #1 Com X
and use another Pixelnet firmware configered dongle #2 Com Y

At least until I get the Smartstring controller.  In this case use a
Pixelnet firmware configered dongle #2 Com Y and use the DMX OUT on the SS Controller
board.  This way only use one dongle.

It is not possible to use only one dongle with pixelmnet firmware unless you have a Smartstring Controller
board in the above configeration.

Thanks,

Greg
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: RJ on June 04, 2011,
No,

 A dongle is either Pixelnet or DMX it can not be both.

So if you want DMX and pixelnet then it is:

2 Dongles
or
1 Pixelnet dongle and use the output of the Hub ( I think you are calling this the controller?) to get you your dmx.

You can have one universe of DMX from each hub.

The Hub is what makes DMX from pixelnet along with splitting the signal and injecting power.

The controllers are the little cheap things on the end of the light strings.

Later the EtherDongle will allow you to have 16,385 channels of pixelnet.

RJ
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 04, 2011,
Yes, I meant the Hub as you described.

 I think I will understand better when I get all this hooked up.

Can't hardly wait..........  This is really cool stuff.

Greg
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 04, 2011,
Thanks,

I have both Pixelnet and DMX dongles connected and found the test hardware feature. Both Dongles are working fine. My main problem at this point is with the LSP scheduler hanging up. I thought that connecting the two types of dongles might correct the issue. It did fix the com port problem that started this thread. So, I am making progress. Maybe there is something else I am missing. It is clear to me now that it is purely a LSP issue.

I'll keep plugging away with the scheduler and have two simple sequences that I am trying to keep looping without it freezing up. I just had the scheduler freeze up with these two and had to kill it with task manager. Frustrating to say the least.

Any suggestions are appreciated.

Greg
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: taybrynn on June 04, 2011,
Hope that LSP 2.0 is better.  I hope so.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 05, 2011,
More Questions about Dongle configs in software:

If using two dongles:
a. One Lynx Dongle with DMX firmware and one Lynx Dongle with Pixelnet firmware?

1. What is the output device of the Pixelnet set to:
a. Pixelnet/Smartstring device
or
b. Lynx Dongle device

2. What is the output device of the DMX set to:
a. Pixelnet/Smartstring device
or
b. Lynx Dongle device


3. What Universe to use assuming only 512 DMX channels and only 4096 Pixelnet channels?
a. Universe 1 for DMX
and
b. Universe 2 for Pixelnet
or
c. Universe 1 for both the Dmx and the Pixelnet

---------------------------------------------------------------------------------------------------------------------------------------------

If using one Lynx Dongle with Pixelnet firmare and SS Hub and using DMX out on the SS Hub.

4. What is the output device of the Pixelnet set to?
a. Pixelnet/Smartstring device
or
b. Lynx Dongle device

5. What is the output device of the Pixelnet set to?
a. Pixelnet/Smartstring device
or
b. Lynx Dongle device

6. What Universe to use assuming only 512 DMX channels and only 4096 Pixelnet channels?
a. Universe 1 for DMX
and
b. Universe 2 for Pixelnet
or
c. Universe 1 for both the Dmx and the Pixelnet

Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: tng5737 on June 09, 2011,
You are not allowed to view links. Register or Login
Pixelnet dongle and use the output of the Hub ( I think you are calling this the controller?) to get you your dmx.
You can have one universe of DMX from each hub.
The Hub is what makes DMX from pixelnet along with splitting the signal and injecting power.

So if using the pixelnet dongle - what do you define in LSP Output Plugin? 
1)just a single instance of PixelNet Output Plugin
2) a PixelnNet Output AND a Lynx DMX Output Plugin
If 1) then is the DMX contl in LSP defined as a Lynx cntl or SSC?
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: mmciver on June 09, 2011,
Do you have all the controllers attached to the dongles that are referenced in the sequence?

I know that when I first fired up LSP I tried to run a sequence out to 1 LE controller, but in the sequence I had Identified 2 - LE's.  I received comport errors when I didn't have the second controller plugged in and powered up.

I don't know if that could be part of the issue or not.

Mike
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: tng5737 on June 09, 2011,
At this point - it is theoretical - I am just trying to figure out how to configure LSP when using DMX passed thru Pixelnet.  Obviously, I could always create a separate output instance for each dongle and run the dmx on the normal dongle, and two universes of pixelnet on two additional pixel dongles.   However, that does not seem like a very efficient use of resources.  I'd rather pass the dmx thru the pixel dongle and split it off at the hub.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 09, 2011,
I will look at my setup tonight and let you know about the comport. I think it just a matter of setting the correct com to the dongle. I can't remember if I set the name for the dongle or not but my pixelnet dongle says pixelnet in LSP. But I may have named it that.

More about this later....

Greg
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: tng5737 on June 09, 2011,
Sort of a moot point right now - I just started getting the same type error msg you referenced in post #3.  Tried re-installing LSP  and drivers to no avail.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: taybrynn on June 09, 2011,
LSP is very controller-centric.  It worries me, because I'm not sure how you change configs (LOR term) when you move stuff around on the hardware
from year to year.  But there are pros and cons to this approach.  So think about setting up your entire SS Hub (pixelnet) as mapping out controllers into your pixelnet universe (or universes).
For this example, we'll map out a Lynx Express (LE) and a  SSC (smart string controller) set to 128 node mode with the SSC firmware programmer.

So I think setting up in LSP is just an exercise in getting all the controllers added and configured as you want.  If you happen to be using the DMX out on the SS Hub, so what ... to LSP, its all PixelNet.
The SS Hub will take care of converting some pixelnet into DMX for you.

As you set up [add] each controller, you specify the type (Light Controller for LE or RGB controller for SSC) ... and the protocol selected would always be Pixelnet (assuming use of a single SS Hub and using the DMX out for your DMX channels on the SSH DMX out) ... but you'd also specify the number of channels and the starting channel  (as you want them mapped out).   See the attached graphic for the optimal order for entering in this information, basically bottom up, which seems backwards to me [ and if you do it top down, you'll likely end up re-doing it unless the defaults are all correct].

So for purposes of this example, lets assume were using Pixelnet Universe 1, and Pixelnet channels 1->512 for DMX.  Everything in 513->4096 is for Pixelnet (SSC/Smart String Controllers only).
Lets also assume your adding a single Lynx Express/LE and a single SSC with 128 nodes, in 128 node mode.

So the LE would be Controller Type=Light Controller + Protocol=Pixelnet/Smart Strings + Zone/Universe=1 + Number of Channels=16 [which you select controller type, specify the starting pixelnet address where you want, it'll consume 16 pixelnet channels].  IF you added additional LE controllers, you would just start each at the correct address, like 17 (instead of 1) for the 2nd LE.

So the SSC would be Controller Type=RGB Controller + Protocol=Pixelnet/Smart Strings + Zone/Universe=1 + Number of Channels=128 [ start at 513 ... it'll consume 384 channels of pixelnet from the starting address you give it ].  

The SS Hub which would take a range of pixelnet (say 1->512) and duplicate that into DMX512 out on SS Hub DMX out, assuming you set the jumper on SSH to use 1-512 for DMX.  Again, like RJ keeps saying its still using 1-512 for pixelnet AND DMX (all the time), but if DMX jumper enabled, its also copying 1-512 into DMX out as well.  Unless you want to shadow channels for some reason (program a DMX and SSC item together) ... you would map DMX into 1->512 and pixelnet into 513->4096 .

So I think you just think of it all as pixelnet.  Its just the SS Hub that converts to DMX for you.  From the software side, your just sending pixelnet to the hub, regardless of what happens after the hub.

If you were to use a second dongle for just DMX, you would probably set it to Universe 2, then map your Light Controller (non SS, like LE) controllers into that instead, and select Protocol as Entec DMX Pro/Lynx instead of Pixelnet.  Everything else the same, and you'd have a 512 channel DMX universe to work with on the second dongle instead.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 09, 2011,
You are not allowed to view links. Register or Login
Sort of a moot point right now - I just started getting the same type error msg you referenced in post #3.  Tried re-installing LSP  and drivers to no avail.

Using two dongles one dmx and one pixelnet, you must set them to two different com ports. This will get rid of the error.
Make sure you change these under the options menu and also check the controllers output in your sequence. LSP is very particular about this.  Make sure to save the sequence after changing the com settings. One other thing is delete the bad output device in the scheduler.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: tng5737 on June 09, 2011,
If you define the LE as Pixenet then the channels will be RGB .   the objects on my LE's are not RGB lights.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: tng5737 on June 09, 2011,
No the problem with the COMM ports was more fundamental than that - the usb serial Comm port had slipped to a number above 9.  This version of LSP does not like Comm ports 10 or above!   Once I set the port below 10 - it worked!

In ref to your above post... the issue is NOT with using two or more dongles - I know that THAT works.  I want to use the pixelnet dongle to xmit both dmx and pixelnet data and let the HUB split off the dmx and the pixelnet.   The question is how to config LSP to do that.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: taybrynn on June 09, 2011,
Quote
If you define the LE as Pixenet then the channels will be RGB .   the objects on my LE's are not RGB lights.


No, its the selection of "Light Controller" or "RGB Controller" which sets the channels as 1 each (LE) or 3 each (RGB) ... not the selection of the Pixelnet protocol.

Think about it, Pixelnet doesn't have to be RGB.  Its true to most SS items ARE going to be RGB, but they don't have to be.

If you select "Light Controller" and Pixelnet at the Protocol, then its still just a 16 channel LE ... because the selection of "Light Controller" tells LSP that its 1 channel per instead of 3 channels per.

Protocol is just telling is what language you want to speak to the device in.  The Controller Type is telling it whether your using 1-per (single channel, non RGB) or 3-per (RGB).

At the end of the day, the DMX out from your SSH/DMX OUT will be sending DMX to your LE ... and they will respond to the DMX signals send to the addresses you assigned them.
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: tng5737 on June 09, 2011,
Yes, indeed you are correct - I just did a little test seq.   and it works exactly as you say!  I think the pop-up channel box (which had the rgb greyed out) was confusing me (not to mention a greatly diminished intellect).   
Thanks, I'm good to go now!
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: wftxlites on June 09, 2011,
Yes, well said.

Also, you want to reserve first 512 for dmx and 513 - 4096 for SS in a single universe.

I see I'm a little late. Dang iPhone.  <md..
Title: Re: LSP Pixelnet Vs. DMX COM Issues
Post by: Timon on June 20, 2011,
You are not allowed to view links. Register or Login
LSP is very controller-centric.  It worries me, because I'm not sure how you change configs (LOR term) when you move stuff around on the hardware from year to year.  But there are pros and cons to this approach.  So think about setting up your entire SS Hub (pixelnet) as mapping out controllers into your pixelnet universe (or universes).

New guy here. This is the very reason I'm not sure about going with LSP. What I'd like to see is the ability to design using virtual controllers then have a map from virtual to real controllers. You could then create shows and map them to any controller configuration you need.

I'd also like to have templates so I could import from LOR and map to the virtual controllers. Those templates should also work for exporting.