Jump to content
Light-O-Rama Forums

DevMike

Administrators
  • Content Count

    3,829
  • Joined

  • Days Won

    63

Everything posted by DevMike

  1. You need to first configure the board (which requires communication). Your Pixel type may not be set correctly which will not allow the pixels to work even with the hardware test.
  2. That's a Windows thing.... Something, somewhere on your computer is running an installation process - it could be another program trying to automatically update itself, or it could be Windows itself trying to do an update. Since Windows wants to track changes by install, only one install can run at one time. Ensure all your Windows Updates are done. Then restart your computer by using the window's start button, power, and then 'Restart'. Don't just power off or select power off - those are not true re-starts in the world of Windows. You must select the 'Restart' option. Once you have done that, give the install another try.
  3. The issue is Windows 7 Windows Media Player and/or Win 7 itself. From what I could gather from Matt's description of the issue, both Windows Media Player and S5 want to use two different DLLs that just happen to have the same name. The problem is these are actually two very different libraries (IE: That other guy you know named Mike is not this Mike :P) That should not be a problem (and isn't in any other version of Windows and or media player or whatever goofy combination this is caused by) since they are in different locations. When a program needs a DLL, usually Windows will search the registry first for DLLs that have been registered. This uniquely identifies them system wide. If they can't be found in the registry, Windows will next look in the folder the program is executing from, again which should be unique (this Mike and that Mike can't be in the same exact space at once). In every other version of Windows: Windows Media Player needs ITS DLL. Windows is returning to it the correct location of its DLL - either because it is registered, or it's in the same folder as Media Player/etc. In Windows 7: Windows is returning the location of OUR DLL to Windows Media Player, not the one it should be. WMP then goes to use something in the DLL and ITS NOT THERE (because it's the wrong one). Bad thigns happen. In this case the 10054 error you are seeing is probably caused by this issue, but not directly. When WMP can't find the routine in the DLL it wants, it panics, barfs up errors and then crashes. When we catch that crash, we panic, barf, and attempt to recover by restarting the show player process. When we do that, all the previous connections become invalid and have to restart - you then see that 10054.
  4. Connect the controller to the USB adapter and start the hardware utility. Status light should go solid after a few seconds. Press the 'Refresh' button and wait. The top center will show the unit once the scan is complete. The first 2 digits are the unit ID hardware utility found the board at. Is it the unit ID you set, or is it different? Remember, ports are units. The first port is the unit you set. The next port is unit +1, then unit +2, etc. Don't forget HEX.
  5. Ok, so let me break this down as best as I can using the PixCon as an example. There are 2 things you need to have a good grasp on - one is 'Protocol', the other is 'Transmission Medium'. Let's talk first about transmission mediums. In the LOR world, there are TWO that we are mainly interested in. RS485 Ethernet There are pros and cons to each of those, as well as differences in how the physically work - we won't get into those at the moment. While both use the same type of cables, sockets, etc they are not physically the same. You can NOT directly connect one to the other. Connecting RS485 to Ethernet (or vice versa) will probably cause bad things to happen as they are VERY different electrically. Notice there is no mention of PROTOCOL here. Let's now talk about Protocol. There are several of them in the LOR world: LOR ELOR DMX A protocol is nothing more than an agreed upon standard to encode and decode data. Basically, protocols are rules: Put this data in this position, use this data to determine what the next X pieces of data are, etc. Notice that there is no mention of TRANSMISSION MEDIUM. The protocol you want to speak is dependent on the systems you are connecting to. These two groups of things, transmission and protocol, are independent of one another and so they can be combined - 1 from A, 1 from B. The thing to remember here is that RS485 was FIRST (historically speaking). That means a lot of times when we talk about things, if it is being sent of RS485 we 'forget' to mention that part. It's implied. When we combine 1 from transmission medium, and 1 from protocol, we give that combination a new name. That new name also comes with additional rules about how the data is sent (we call that 'encapsulation' or 'wrapping' or putting data into an envelope. While there is nothing wrong with making any combination of 2, at this time only some combinations are actually supported. So for example, when we talk about LOR and ELOR protocol, we are always talking about something sent over RS485. Not because there would be anything wrong with sending LOR/ELOR over Ethernet - we simply don't do it because we have not written code to make it happen. If we did, we would give it a name, probably something along the lines of LOR/ELOR ACN. Which leaves us with DMX. DMX can be transmitted over BOTH transmission mediums. When we send DMX over RS485, we call it (simply) 'DMX' - Remember, RS485 came first. Back then DMX described BOTH the protocol and the transmission medium. It probably would have been better to rename it something like DMX-SERIAL or E1.11 (which is the standard name for DMX over RS485). But several years later, the need for more channels and more speed meant that DMX was running out of bandwidth. So the ESTA decided to divide DMX into two pieces. The fist piece would be called 'DMX' and is identical to what has been out there for years and years. The other is called E1.31 (More correctly called 'streaming ACN', but no one uses that). E1.31 is simply DMX protocol that is transmitted over Ethernet. Summary: When talking about LOR or ELOR, we are always talking about a protocol that is transmitted over RS485. When we are talking DMX, we could be talking about RS485 transmission, OR Ethernet transmission. Most people will make the distinction by saying DMX or E1.31, but not always. If you are unsure from context you should always ask. Continuing... Transmission Medium is something PHYSICAL. By that we mean there are very different physical attributes of the signals on the wires. This could mean differences in voltage, amperage, etc, so transmission media are kept to SEPARATE physical connections. On a PixCon16, you will see several RJ45 ports - those keystone looking sockets. One of these is metal, the others are plastic. There are reasons why the one is metal, but they are technical and don't need to be discussed. The metal jack on a PixCon16 is for Ethernet (only). The 5 plastic jacks are for RS485 (only). So in order to run E1.31 (which is DMX over ETHERNET), you need to use the metal jack. It is the only jack capable of Ethernet. If you are running LOR or ELOR protocol, you'll be using 2 of the 5 PLASTIC jacks - the two stacked one on top of the other. You still didn't answer my question, Mike OK, so now you are really shaking your head. What I have just told you is that you are either going to use the metal jack (for e1.31) and NONE of the plastic ones, or only 2 of the 5 plastic jacks for LOR/ELOR. WHAT?! Why have all those jacks? So we know that long ago there were these DMX devices that ran on RS485. In fact, 95% of theatrical lighting devices STILL run on DMX over RS485. Wouldn't it be nice if we had some kind of board that let you go from E1.31 (so you could take advantage of the higher speeds/etc it offered), and then convert that to DMX over RS485 to be able to use all these other devices? THAT is what those other jacks are for. You can configure a Pixcon that is running E1.31 to act as a 'BRIDGE' to go between E1.31 (DMX over Ethernet) and DMX (DMX over RS485). Since there is no such thing as LOR protocol over Ethernet, even though those jacks that can run RS485, you won't connect LOR devices to them (at least, not in LOR protocol mode. Keep reading). Oh Cool! I can run 4 regular DMX devices from a PixCon16 then? Nope. You can run 4 UNIVERSES of devices! One more thing to learn about RS485. if you think about LOR controllers in general, like our 16 channel controllers, etc, you'll see that each one of them has TWO RJ45 jacks on them. One is for IN (from a previous controller) and the other is OUT (to the next controller). The PixCon is no different in this respect when it comes to using it - it has an IN and an OUT. Physical DMX can do the same things - you can 'daisy chain' multiple devices together to the same universe. So each one of those 4 jacks is the START of a separate DMX Universe And since it is the START of a string, it only needs 1 jack per universe. Only one of the 'double stacked' plastic jacks is going to be used. So can I DRIVE the PixCon16 with DMX over RS485 data? No. And the reason for that is because DMX protocol itself does not allow for the number of channels required to drive pixels. There are only enough channels in the DMX protocol to handle 170 pixels. The PixCon16 can drive over 5,000. What about the other 4800+ pixels? So then I can only drive 170 pixels on the PixCon using ELOR? Nope again. Remember the limitation we talked about is on the Protocol, not the transmission medium. ELOR protocol allows for many thousands of pixels since it is designed to handle them. Want to learn a little more about DMX, E1.31? Read the "An Introduction to DMX and E1.31 for Pixel Control" document we created several years ago. What's the catch? If I can drive as many pixels on ELOR as I can with E1.31, why would I go through the expense of adding network switches, routers, etc? Actually that is not what we said. I said we could drive many thousands of pixels on ELOR (RS485), but I never said you could drive as many pixels as on E1.31 (DMX over Ethernet). The reason you go with E1.31 is that it has a HUGE advantage when it comes to Bandwidth over RS485. You can transmit the data for 100,000 pixels over Ethernet and not break a sweat. Ethernet is MUCH MUCH faster. If E1.31 is so much better, why support RS485 at all for Pixels, IE, PixCon16 in ELOR mode, or PixieXX controllers? Because E1.31 can get complicated in a hurry, and not everyone needs more than a few thousand pixels. Is there ANY way to drive LOR controllers over E1.31? Yes. Almost all of our controllers understand BOTH LOR and DMX protocols! So let's say you have a PixCon16 and 3 LOR 16 channel controllers. You are already running the PixCon16 with E1.31. Address your LOR controllers NOT as LOR controllers but as DMX devices (see the manual for your controller). Your PixCon16 takes the E1.31 commands, BRIDGES them to RS485. Taking it full circle.... So why doesn't everyone buy PixCon16s? Why sell Pixies at all? The PixCon16 is a VERY powerful board. On a single network with a single cable per device you can run hundreds of thousands of channels of all types: pixels, AC, Servo, DC. You could have strings of hundreds of AC controllers, a pixel tree that required 4 PixCon16s itself. When it comes to flexibility and functionality the PixCon is second to none. But all that flexibility comes at a VERY steep cost - learning how to use it. The PixCon has so many features, and different ways that those features can be used, that is quite easy to get it into a state where it does NOT do what you want.
  6. You may occasionally see 10054/10061 errors in the log for the LOR Comm Listener. These errors are usually followed with some error description text that is similar to " An existing connection was forcibly closed/rejected by the remote host". The text can be different, but the general gist is that someone closed a connection to someone else. These errors are transient and a normal part of Ethernet communication. They happen all the time on your LAN without you noticing, or even between different software on the same computer using TCP/IP to communicate. In almost ALL instances, simply ignore the error. If you are having an issue with the LOR software, this is most likely not a cause or a symptom. What those errors boil down to is that someone tried to send data to someone else, and something happened to that data. Either it was corrupted, the transmission timed out, the connection went down, etc. When this error occurs, the connection is closed by the side detecting the error, a new connection is automatically established, and the data is re-transmitted. If you are seeing a few of these, or even more than a few over a long period of time, there is nothing to worry about. Nothing is wrong, and things are working exactly as they should. If however you are seeing hundreds of these a minute, then there is an issue with your network somewhere, or possibly with the computer itself that does need to be looked at.
  7. I don't see a 719009 either.... I do see where you have 2 tickets (neither ending in 009). I'll use the new one to get you replacements. Just leave the other one closed please.
  8. In his PM to me , he typoed the ticket as 709009. That was what I checked. I'll make sure Dan knows about 719009 then.
  9. Wow, sure would be nice if there was a company that stands behind their strips and warranties them, huh?
  10. Today we released production version 5.3.8 of the Light-O-Rama Software Suite. This is an official production release, not a beta release. S5 fully integrates the Pixel Editor, Sequence Editor, and Visualizer into a single program and adds many enhancements to help you program large channel count stages. S5 uses a different methodology called 'Visual Sequencing' to create amazing sequences and has new automatic programming tools called 'Motion Effects' that will speed your sequencing. For more information on S5, please see the "Sequencer (Showtime 5)" section of our Tutorials and PDFs page on our main website. The latest S5 help can always be found online here: http://www1.lightorama.com/downloads/5.3.8/help/ How to check if your license covers this version To check whether or not your license covers this version, please go to the license retrieval page, and enter your email address (the one you purchased your license with). An email should then be sent to you with information about your license. The "Summary" section of the email will tell you whether or not your license covers the latest version. If the email says... Your license covers the latest version, 5.3.*. ... then your license already covers this version. You can use it without making any additional purchase. Please note, though, that your computer may not yet understand that your license covers this version, so when you install, it might tell you that you are running in Demo mode. In this case, simply reactivate your license (for example, via "Upgrade Light-O-Rama" on the Sequence Editor's "Help" menu), and your computer will then learn that your license is valid for this version. On the other hand, if the email instead says... Your license does not cover the latest version, 5.3.*. ... then your license does not cover this version. In that case, you have several options: Upgrading or Renewing Your License (1) You can continue using whatever version your license does cover (for example, perhaps your license covers version 4.1). (2) If you want to take this opportunity to increase your license level to take advantage of additional features, you can purchase a license level upgrade. This counts as a license renewal too - that is, your license will now work with this new version (and some future versions too). So, if you do this, there is no reason to also purchase a license renewal. (3) If you already own a Light-O-Rama license, but you do not currently own Light-O-Rama SuperStar, or if you want to upgrade SuperStar to a higher number of CCRs/channels, you could purchase or upgrade SuperStar. This also counts as a license renewal for the rest of the Light-O-Rama software suite, so if you do this, there is no reason to also purchase a license renewal. Please note that you must already own a license for the rest of the Light-O-Rama software suite in order to take this option. (4) If you do not want to purchase a license level upgrade or Light-O-Rama SuperStar, you can purchase a license renewal. Your license will now work with the new version (and some future versions too), at the same license level as it currently does. For example, if you have an Advanced license, it will remain an Advanced license, but it will now cover the new version of software. What's New in Version 5.3.8 Various Sequencer Enhancements Bug Fixes How To Get the Latest Version You can download the new version from the software download page. If that page lists a different version number as the latest version, please click your browser's refresh button. Thank You!
  11. There is a planned (by the power company) outage in Hudson Falls which is affecting manufacturing, distribution, and main offices of LOR today 9/20/2019. We will not be shipping today, and phone support is not available due to the power outage. Help requests are being serviced on the helpdesk at http://helpdesk.lightorama.com/ should you require any assistance. We should be back to normal operation on Monday 9/23/2019. We are sorry for any inconvenience.
  12. I'm glad that got it working, but I am still worried about Network Preferences in 5.3.6. Is anyone else seeing anything weird with it like runtime errors? The only runtime errors I remember seeing in there where from newer firmware not playing nice with the IP troubleshooter long long ago.
  13. If you are still experiencing this error, please open a help desk ticket. Usually that is caused by 1 of 2 things: 1 - You have an incomplete install/uninstall that has killed some DLLs. A full uninstall/registry wipe/re-install will fix it. 2 - You have a bad registry value. This was fixed years ago, so I doubt it is your issue. In any event, following #1 will also fix this (if you use the registry wipe)
  14. I'm also going to reply to your ticket, but I wanted to let others know here. The RunTime error 9 in the Network Preferences was a bug that was fixed in newer versions of S4/S5. I don't remember which exact version it was fixed in, but 4.4.4 should definitely have it. I suggest you upgrade to that version.
  15. Ok fellow residents of the great state of FL, let's check in and be safe out there this coming week. I know a lot can change in 3-4 days, but Dorian looks like it's going to affect pretty much all of us. Prepare. Be safe. And most importantly - check in NOW with your neighbors and then again after the storm when it is safe.
  16. The secret sauce is: TRUE SINE WAVE. Your inverter or generator MUST output true sine wave. Not 'Modified Sine Wave', not 'Square Wave', not 'Safe for electronics'.
  17. The only reason Jim and I disagree on this (and even then, see below) is that I have to take an official stand - when you support this stuff, you need to have some firm rules. In the interest of full disclosure - yes, we have VERY RARELY recommended to customers that they use a Y. Typically it's an emergency situation where the customer simply can't remove a controller with a bad RJ45 from their chain. We also tell them that once the emergency is over, they need to send it in for repair. Other than that, we say no. We especially say no when it's to run in 2 directions. So if you have a broken RJ45, AND you are stuck, we'll tell you that you can temporarily do it. But if you ever ask us for support and tell us you have one, that will be the first thing we tell you to remove. Otherwise we end up chasing ghosts (reflections).
  18. LOR Controllers, along with DMX universes have a hard cap on the channel number of 512. The issue you are having is that you are 'packing pixels'. You should not 'pixel pack' (IE, use EVERY address available to you) as it just leads to this kind of frustration - EVEN IN DMX mode (which you are not using if you have Pixies). Early pixel controllers FORCED you to pixel pack. Newer ones (like ours) do not. Let's look at an example of a theoretical pixel controller. This pixel controller has 8 ports, and each port can support up to 170 pixels per port. To this pixel controller you connect only 100 pixels per port. Not Pixel Packing: Each string starts at it's own network identifier (in the case of LOR, that would be NET and UNIT, in E1.31 it would be universe). Pixels on that port are numbered from 1-100, and therefore consume 300 channels (1-300). 212 of the possible 512 channel IDs will simply not be used (301-512). Pixel Packing Pixie controllers do not allow you to pixel pack. For E1.31 controllers (DMX over IP) the first string starts at the network identifier (Universe). Pixels on that first port are numbered 1-100 and consume channels 1-300. The SECOND string on the SECOND port however continues from the first. The first 70 pixels will have the SAME network identifier (Universe) as the first string. The first 70 pixels will be numbered from 101-170, and will consume channels 301-510. But what about the last 30 pixels? Those will move to the NEXT network identifier (universe), and will start over with pixel 1-30 (channels 1-90) - your network ID just changed in the middle of a string. You next full string will be on the next port but start at that network identifier, and the first pixel is number 31 and will run through 130. The next string is on the next physical port, starts at pixel 131. It will run for 40 pixels at which time the network identifier changes again. Are you confused? Yes you are. Remember what I said about being able to QUICKLY identify a particular pixels address correctly? Not packing makes it SUPER easy. Packing on the other hand requires that you know how to do a lot of math. The ONLY advantage pixel packing has is that it allows you to use LESS network identifiers (Network and Unit ID). There is no reason for that - long before you run out of network identifiers, you'll run out of bandwidth. So REGARDLESS of what protocol you are using (LOR or E1.31), DON'T PIXEL PACK. It is OK TO WASTE those channel IDs.
  19. In my classes I always describe 'channel' as being the 'smallest unit you can control'. Notice there is no mention of color, or even POINTS OF LIGHT (since channels can control other things like Servos, etc). So if you have a bush that has 2 different colors of regular lights on it, and you connect it so that each single color can be controlled. THAT is the channel: Bush, Blue or Bush, Red. 1 channel controls 1 color for that entire bush. If you want the bush blue, turn on the blue channel for it. If you want it blue and red, turn on both. If you have another bush and put 2 different channels on it each of those 2 bushes can blue, red or a combination at any time. 2 bushes times 2 colors = 4 channels. RGB: RGB just refers to the mixing of different amounts of those 3 colors to make ANY solid color. Since we need to control the amount of each of those colors, we need 3 channels: One for each. Now you have the same bush, but you instead use DUMB RGB. The smallest unit you can control is still a channel - blue or red or green. However because those 3 LEDs are in the same lens, they mix and now you can have any color. We sometimes call that an RGB channel but that is not correct. It's really an RGB group. But at the end of the day, you are still only going to control 'the bush'. Also remember that RGB has absolutely nothing to do with the concept of 'PIXEL'. RGB just tells you that whatever it is, that particular thing can be any color at any time. Pixel: Pixels are individual bulbs on a single string that can be controlled. TECHNICALLY nothing says they have to be RGB (but 99.995% are -- keep reading). For now lets just say they are ONE color, AND NOT RGB. That is perfectly legal! Older pixel technology was single color (white light) ONLY. So in this case the smallest unit you can control is 'the pixel'. It will either be ON or off. The number of pixels is the number of channels required: 50 pixels = 50 channels (remember we are NOT RGB!). The smallest thing you can control is a single point of light. Pixel + RGB = SMART pixels: BUUUUUT.... As I said, nearly ALL pixels are also RGB. That means that where before we used 1 channel to control a pixel, now we need to use 3. Remember? We can control the color, and controlling color requires THREE inputs: the amount of Red, Green, and Blue to mix. If you want the 5th pixel to be red, you turn on THAT channel. If you want the 23rd pixel to be BLUE, turn on that channel.... ... and again, because these are RGB bulbs (remember: RGB is nothing more than 3 LEDs in the same lens that can be mixed) you can use the 3 channels assigned to that pixel to make whatever color you want. RGB channel? :So why do we sometimes (most of the time) call it an RGB channel instead of an RGB group? We probably shouldn't, but we do. It goes back to the notion of 'Smallest unit you can control'. In your mind, you set a color to an RGB 'thing'. 'Color' in this case is singular - you wouldn't consider programming an RGB item in any other way. TECHNICALLY however, that color is composed of the mix of those 3 different components. Each of those components is a channel. UNIT: So, as you can see with high channel count devices, things can get out of hand in a hurry. That is where the notion in the LOR world of UNIT comes into play. Think of a Unit as being the smallest DEVICE that you are addressing. Some controllers are single devices, like our 16 channel AC controllers. Other controllers however have MULTIPLE devices, for example our PIXIE controllers. A Pixie 8 is a single board that houses EIGHT devices. In this case, each device is an output port on the Pixie. Lets examine that a little more and show you why we do it that way. A Pixie 8 can have a maximum of 1,360 RGB pixels attached (There are 8 ports and each port can run 170 RGB pixels. 8*170). And don't forget that each of those pixels, because they are RGB, require 3 channels. That means that one board controls 4,080 channels. If you have 5 of them, your channels would be numbered from 1 to 20,400. So quick! Tell me which is the RED channel on board #3, the 5th port, 23rd pixel? Without a lot of math, you can't. Let's make that easier by giving each port a unique, separate ID. So board 1 get's IDs 1-8 (we set the board to starting address 1 and it consumes 8 UNIT IDs). We set board #2 to 11, board #3 to 21, board 4 to 31, and board 5 to 41. (yes, we are skipping some numbers) So board 3 starts at 31. Port 5 is ... 35 obviously. That's easy enough. Now we need the 23rd pixel. When you look at your sequence or preview, you'll can quickly find unit 35, pixel 23. If you really need to know, expand pixel 23 and find it's channels 67,68,69. U:35,C:67 is much easier to remember and find than 4997! Address: You need to know that an 'address' in the LOR world is the complete identifier to a particular 'smallest unit you can control'. An address consists of THREE parts: We've talked about channels being the most basic unit. From there channels are grouped into Units ( also called devices or controllers). We also allow you to group units, and a group of units is called a NETWORK. NETWORK: Just to completely round out this discussion of 'addressing' lets talk about Networks. Your home address consists of The State and City (Network), the Street (Unit), and finally the numeric address (channel). LOR networks are the same. You can have up to 16 different networks, and they are named REGular, AUX A, AUX B...,AUX O. Many people only have a single network, so we tend to ignore it when we talk about addresses. We say things like U:30, C:15 where we just assume the network is REGular. If however you have more than 1 network, you must identify it. REG, U:30, C:15 is a different address than AUX A,U:30,C:15. There are many different reasons to use multiple networks, but typically it is due to the upper limit of channels allowed on a single network. So now you should have a firmer understanding of: Addressing: Channels (also called 'Circuits) - the base of all addressing Units (also called 'Devices' or 'Controllers') - collections of channels Networks - collections of units. Pixels Individual points of lights that can be individually controlled on a single string May or may NOT (but almost always are) RGB RGB Talks only of mixing different amounts of Red, Green and Blue to form any color. Says nothing about if lights on a string are individually controllable or not Almost ALWAYS pixels (also called SMART strings) are RGB, but there is NO requirement. RGB and Pixel are separate concepts Some strings/ribbons are DUMB. You can control the color, but not WHICH point of light is on. They are all the same color.
  20. I do my part: Anyone I talk to on the phone is told skip the black go for red and spend the $2 When we say black or red, we are talking about the small T-Shirt adapters, not the B/ISO ones. FYI: the ISO one CAN do 500K (and happens to be black). The B one can NOT. Read about it in boring detail here: http://www1.lightorama.com/network-speeds/ This is the one of the FEW things that Jim and I disagree on (wow. Not many of those!) Unless provided for on the adapter (like the B or ISO or Repeater), we do NOT recommend splitting the RS485 signal. Impedance mismatches will cause signal reflections causing all kinds of problems. In our adapters with 2 jacks, each jack is isolated from the other. You placing a Y connector will not isolate the 2 segments. You'll have an impedance mismatch/timing mismatch which could cause signal reflections from one side distorting the actual signal on the other. Now.... Can you do it? Yup. Will you have problems? Probably not - we use high quality transceivers which are pretty good at rejecting noise. But 'probably' is not 'never'. If you do end up with signal problems, one of the first things we are going to tell you is to make sure you don't have an Y's. Just as an FYI, here is our helpdesk response for troubleshooting network issues: What you are describing is probably not a problem with any particular controller, but a problem with your data network in general.The first thing to do is move a particularly troublesome controller to the end of the string of controllers and then try both RJ45 jacks. You can also run a phone line between the second to the last and this controller and use the RJ11s and see if this helps.If you still have issues the most likely cause is going to be a problem on your data network SOMEWHERE -- not just near this troublesome controller.The nature of RS485 communications can mean a problem with a cable or other interference is actually anywhere on the network, not just between 2 controllers that exhibit symptoms. It is important to remember this while working through some of the suggestions below. A problem that is actually between controllers 2 and 3 can appear between controllers 12 and 13. We must stress again -- It is very important that you remember this fact while troubleshooting.There could be multiple issues with your network, and that finding the problem is a matter of trial and error. The first and easiest thing to check is to make sure NONE of your data cables are running parallel or near any electrical cords. Data cables should never be bundled with power lines, or cords going out to your lights. If it is necessary to locate a data cable near an electrical line, be sure they cross at a 90 degree angle or they are kept at least 12-18" away from each other (or more). Ensure your network is not physically too long. RS485 communications is good for a MAXIMUM of 4000' at 19.2K in IDEAL conditions. In real life distances can be much shorter. Higher speeds are more likely to have issues, but you should still be able to go many hundreds of feet. If you are starting to bump close to the 600-700 foot range using higher speeds (above 57.6k), you may want to consider an RS485 repeater or splitting your network onto 2 or more USB adapters (see below). A single RS485 network should NOT have any Ys or other splitters. RS485 should be strictly POINT TO POINT. If you are using a splitter or other device (with the exception of an active RS485 Topology Extender/Repeater), you need to remove them. You can NOT use both RJ45s and the RJ11 of a controller at the same time. You may need to add a 'terminator' to the end of your controllers. Data reflections can occur at the end of the RS485 data line causing data to be corrupted anywhere along the chain of controllers. If you have a new Pixie controller (one that has dip switches), we recommend you place that controller at the END of the line and then place a jumper on JP4. If not, you can create your own terminator. To build your own terminator, use a 1/4 w 120 ohm resistor and place it between pins 4 and 5 of an RJ45 jack. Start replacing the data lines between the controllers, starting with the one from the USB adapter to the first controller. A cheap CAT5 cable tester can help identify cables that have broken wires/bad connectors, but is mostly useless for testing marginal data networks. A marginal cable can test just fine with one of these testers, but have too much internal resistance/impedance which renders RS485 communications unstable further down the line. You may find that on some days you have no issues at all, but on others you experience many. You may also find that during a show things start to work better, or get worse. All of this is the nature of RS485. Temperature and humidity changes do have an affect on RS485. If you have a marginal network already, a small weather change is all it may take to go from working to not. If you find that none of these suggestions help, you may be in an electrically noisy environment. Depending on the complexity of your sequences, you may wish to go into the Network Configuration and reduce the speed of your network. The slower the network speed, the more resilient it is to noise. However, slower communications speeds may impact your sequences. In general, you should use the slowest speed that correctly renders your most complex sequence.The last step is to break the network into 2 or more parts. Data cables can actually become large antennas for electrical noise. The more antenna there is out there for a network, the more susceptible it is to picking up electrical noise. The LOR Advanced software and above can run 16 separate data networks. By splitting your controllers into 2 or more networks, you reduce the run length and increase noise suppression. For each new network, you would purchase a new USB RS485 adapter, and then assign the adapter to a new network (AUX-A through AUX-O are available). Move some of your controllers physically onto this new network and then update your sequences so that the channels point to the correct network.
  21. If the sequence identified and you are trying to schedule is a LOR S5 sequence (.lorprot or .loredit), you can ignore that. It's not really an error, it's Verifier not understanding that you can now schedule those file times. If the sequence identified is a legacy sequence and you are trying to schedule that (.LMS, or .LAS) then this error still applies - there is something wrong with that sequence. Check the help file for more information.
  22. In case you missed the announcement forum, 5.3.6 has been released this morning.
  23. Today we released production version 5.3.6 of the Light-O-Rama Software Suite. This is an official production release, not a beta release. S5 fully integrates the Pixel Editor, Sequence Editor, and Visualizer into a single program and adds many enhancements to help you program large channel count stages. S5 uses a different methodology called 'Visual Sequencing' to create amazing sequences and has new automatic programming tools called 'Motion Effects' that will speed your sequencing. For more information on S5, please see the "Sequencer (Showtime 5)" section of our Tutorials and PDFs page on our main website. The latest S5 help can always be found online here: http://www1.lightorama.com/downloads/5.3.6/help/ How to check if your license covers this version To check whether or not your license covers this version, please go to the license retrieval page, and enter your email address (the one you purchased your license with). An email should then be sent to you with information about your license. The "Summary" section of the email will tell you whether or not your license covers the latest version. If the email says... Your license covers the latest version, 5.3.*. ... then your license already covers this version. You can use it without making any additional purchase. Please note, though, that your computer may not yet understand that your license covers this version, so when you install, it might tell you that you are running in Demo mode. In this case, simply reactivate your license (for example, via "Upgrade Light-O-Rama" on the Sequence Editor's "Help" menu), and your computer will then learn that your license is valid for this version. On the other hand, if the email instead says... Your license does not cover the latest version, 5.3.*. ... then your license does not cover this version. In that case, you have several options: Upgrading or Renewing Your License (1) You can continue using whatever version your license does cover (for example, perhaps your license covers version 4.1). (2) If you want to take this opportunity to increase your license level to take advantage of additional features, you can purchase a license level upgrade. This counts as a license renewal too - that is, your license will now work with this new version (and some future versions too). So, if you do this, there is no reason to also purchase a license renewal. (3) If you already own a Light-O-Rama license, but you do not currently own Light-O-Rama SuperStar, or if you want to upgrade SuperStar to a higher number of CCRs/channels, you could purchase or upgrade SuperStar. This also counts as a license renewal for the rest of the Light-O-Rama software suite, so if you do this, there is no reason to also purchase a license renewal. Please note that you must already own a license for the rest of the Light-O-Rama software suite in order to take this option. (4) If you do not want to purchase a license level upgrade or Light-O-Rama SuperStar, you can purchase a license renewal. Your license will now work with the new version (and some future versions too), at the same license level as it currently does. For example, if you have an Advanced license, it will remain an Advanced license, but it will now cover the new version of software. What's New in Version 5.3.6 Crash fix for Sequencer Various Sequencer Enhancements Bug Fixes. How To Get the Latest Version You can download the new version from the software download page. If that page lists a different version number as the lastest version, please click your browser's refresh button. Thank You!
  24. Sorry folks. We had some minor issues with our server today that pushed us past the time we could get the build finished. It will be out tomorrow morning.
×
×
  • Create New...