PDA

View Full Version : Lights hault but music still goes on, what can I do?



ibby
12-07-2012, 02:52 PM
Joe,

It appears I have some issue with my show. It will run thru a play list for a while then all of a sudden it won't turn the lights on either from Renard on Com 1 or E131 to my E681 board. After the sequence is over maybe it will start working or not. Sometime if I let it play thru on it own it will correct after several playing. Other times I just have to shut down HLS and start the playlist over again. I am using HLS 9D right now.

I do have a output-debug file but it is really large 45MB. Anything I should look for on the output (I looked at it and can't make heads or tails of it) or do I need to upload it to the message board?

ibby
12-07-2012, 03:04 PM
Here is a dropbox link to the output file. https://www.dropbox.com/s/qtzxxqe8zaczoay/DebugOutPutDataStreamShow.txt

BrianJ
12-07-2012, 03:28 PM
This happens to me once in a while if I am actively doing something else on the PC when the sequences change in the play list. It always loads the next sequence properly if I leave the PC alone. I just chalk it up to not enough computer to do a show and other things at the same time. (2.8GhzCoreDuo with 4 gigs RAM)

JHinkle
12-07-2012, 03:52 PM
HLS uses Window playing the audio for timing.

HLS tells Window's to "CallBack" every 25, 50, or 100 msec of audio being played.

THAT CallBack is then used to output to the lights.

If your sequence stops as you describe --- is the music still playing?

Are you doing something that would affect audio being played.

I see no info in the debug file -- so if things just stop - I'm thinking the audio allBack has stopped.

Do you recall audio going off?

Joe

ibby
12-07-2012, 04:48 PM
Music is still playing. I am not touching the computer at all. I have tried to turn everything off that I can on that computer so it can be dedicated to HLS.

JHinkle
12-07-2012, 04:57 PM
Please explain in detail.

Is E131 always working?

Is it just the COM related outputs?

Joe

BrianJ
12-07-2012, 05:26 PM
Mine show is E1.31 only. When it occurs here the whole song has no lights but the music still plays fine. when the next song/sequence starts evreything is back to normal. Both sound and lights play fine. As I said above, it only happens here if I am doing other tasks on the PC when the sequence is changing. (from one sequence to the next in the playlist)

JHinkle
12-07-2012, 05:36 PM
Are you getting any sort of an Error MessageBox from HLS?

I will only give it once even if the error occurs multiple times? This would be an error Sending the data if one occurred.

Joe

ibby
12-07-2012, 05:46 PM
I get lights that are frozen on in some section of my yard that are Rendard (I am only using Com 1). E131 lights are never turn on/ or frozen on when this happens. I have not seen any message box on the computer. Would it be something that I have to acknowledged or would it just flash and go away? I will watch more carefully tonight. Usually starting the next song will correct this sometimes not.

BrianJ
12-07-2012, 05:49 PM
no error box, everything just runs like normal. I have not checked in the dialog box of the scheduler to see if anything showed different there.
This has happened twice for me now, that I have noticed. The first time my wife came home and said why aren't the lights on. They are I said then went to look and saw complete darkness. I had my mp3 player/ radio on and was listening to the show the whole time. By the time I went back to the computer to check, it was loading the next sequence and everything played ok

JHinkle
12-07-2012, 06:06 PM
I am adding some additional debugging info and REMOVING the actual data stream info. I don't want disk activity to come into play.

I am currently accepting SEND error of "Would Block" without notification because it really isn't. It WILL be reported in the new Debug reporting to see if that is having any impact.

Version 9G will incorporate the new debugging - released shortly.

Joe

JHinkle
12-07-2012, 06:32 PM
Version 9G is released.

Make sure your DELETE the Old Debug file prior to starting HLS.

HLS just Appends info to the file --- this will keep it small.

Joe

BrianJ
12-07-2012, 06:48 PM
Joe I will update after tonight's show and test tomorrow :)

As always, Thanks

ibby
12-07-2012, 06:59 PM
Joe, I will install and run it tonight. Thanks!

Henedce
12-08-2012, 01:37 AM
Upgraded to 9G and the issue for me is still there .. Seems to be purely random

ibby
12-08-2012, 02:38 AM
Joe,
Here are two different output files. The lights stopped working most of the night. There was not other applications runnging and I was not using the computer at all.
https://www.dropbox.com/s/oi6z7bbbouu8coe/DebugOutPutDataStreamShow-Dec7.txt
https://www.dropbox.com/s/sd3b6l0rwcze67o/DebugOutPutDataStreamShow-TJI-Dec7.txt

angus40
12-08-2012, 02:41 AM
Check all your cat5/cat6 contacts no data =no lights .

Henedce
12-08-2012, 03:14 AM
Check all your cat5/cat6 contacts no data =no lights .
The issue isnt a connection .
Everything works fine with no one anywhere near any controllers or the PC and it just randomly stops.
Next song starts all is well
Can last 1 song 5 songs 9 songs 1 hr 5 mins 3 mins 2 hrs etc
Im guessing its a comm port conflict but buggered if I can find it ..

angus40
12-08-2012, 03:49 AM
Hendence , i am using a rpm's e1.31 to dmx bridge , after trying vixen and having the comport access denied situation I ordered the bridge and have had 0 interuptions .

angus40
12-08-2012, 03:51 AM
Henedce has exceeded their stored private messages quota and cannot accept further messages until they clear some space.

Henedce
12-08-2012, 04:18 AM
Id love to just do that but I wont recieve in Australia this side of Christmas.
Next year im all pixels anyway so a bit of a waste of money to.
Im dealing with this issue just means I have to watch my show the whole time and restart as required .
I wish it was as simple as comm port denied. I even swapped out my ren boards and all cables today to no avail.
Been running for 6 hours now and it will run 2 hrs no problem then crash every song for a couple , then 1 hr then half a song , always different spots in a song (thought maybe i confused the data with a double up )
Tried turning off everything on the PC but whats needed , rebooting , removing all non essential hardware , Using the XP drive in the PC installing and uninstalling drivers , Swapped out all the ram , only thing i cant do is use a different PC as none have serial ports .
Tried disconnecting the dvd drives , changing the ren inputs from 232 to 485 and back .
Tried running with vixen ( no crashes for the 2 hours it ran.
So as I said I believe its a conflict with the way HLS sends data and my Comm port.

Henedce
12-08-2012, 04:27 AM
Joe

Init Com Port - Current Baud 57600

Init Com Port - Wanted Baud 57600

Init Com Port - Current Parity 0

Init Com Port - Wanted Parity 0

Init Com Port - Current Stop 0 <------------ Just noticed this on all my debug files . Is this Stop Bits and shouldnt it be 1 ??????

Init Com Port - Wanted Stop 0

JHinkle
12-08-2012, 07:18 AM
NO - Parameter value for number of STOP bits. 0 == 1 bit, 1 == 2 bits.

I changed this post - earlier I made incorrect statement.


Joe

JHinkle
12-08-2012, 07:25 AM
Removed - post ... still asleep when I made incorrect conclusion.

Joe

Henedce
12-08-2012, 07:29 AM
From my export file for the same sequence
<UniverseNumber>11</UniverseNumber>
<Transport>COM</Transport>
<ComPortNumber>1</ComPortNumber>
<Baud>57600</Baud>
<Parity>NOPARITY</Parity>
<Stop>ONESTOPBIT</Stop>

JHinkle
12-08-2012, 07:37 AM
My mistake - code is OK - that's what happens when one makes a quick conclusion.

The Debug file is reporting the actual numeric value that Windows want - NOT the actual number of STOP bits.

Windows uses defines ....

ONESTOPBIT = 0;

TWOSTOPBITS = 1;

So ... the code is right - the debug file is misleading with the value. The intend of the debug was to compare Values to see if the driver or some other process was changing things.

So .... we are still back trying to figure out what is going on.

Can you send me the complete Debug file so I can examine it.

Thanks.

Joe

Henedce
12-08-2012, 07:56 AM
Debug attached . Its big been running for several hours . Think there are around 8 - 10 crashes in there.
Im going to try moving one board to comm3 tomorrow (too late tonight now).
The only time I have run with no errors is when I had no renard boards daisy chained .
Will let you know what happens..

JHinkle
12-08-2012, 08:19 AM
The Debug file says HLS is putting out the data without issue.

You stated your issue occurs when renards are daisy-chained. Is E131 still OK when the renards stop?

I wish a renard expert would voice an opinion. I've added the extra padding every 100 bytes.

How can I get source on the Vixen Renard driver. I would look at the source and see what OTHER suttle things need to be done to keep a string of daisy-chained renards working.

Joe

JHinkle
12-08-2012, 10:53 AM
Looked hi and low and could not find the source for any Vixen Renard Plugin.

I looked at the output module for Xlights and they just force Renard COM to always be 2 bits STOP as opposed to do any padding.

Version 9H is kind of a Renard COM test ....

I have BOTH 100 byte padding AND 2 bits STOP.

All indications point to a race within the Renard daisy-chained controllers --- we will see if this "slow down" helps.

Joe

ibby
12-08-2012, 12:27 PM
Joe,
I will run this today but I have a question. If you think it Renard daisy channed controllers why does the E131 stop working also?

JHinkle
12-08-2012, 12:40 PM
I did not know both stopped.

Henedce eluded that everything was fine as long as no daisy-chained renards were used.

Please delete your current Debug file and use the latest version of HLS.

I have made several small changes to COM communication attempting to find root-cause.

The debug file will not be large as I am no longer gathering illumination debug data in SHOW mode.

Thanks.

Joe

ibby
12-08-2012, 01:30 PM
Joe,

I have 3 ren24 that are daisy chained together and one e681-6 board. All of my sequences start with Renard channels going on first then at some point in the sequence the E131 channels.

I just loaded the new HLS 9k and ran my play list of 4 sequences thru. The problem started with the first sequence "Kisses", The mini trees lite up the first color then stopped (frozen in Green when they should be changing colors). The E131 Mega Tree that is suppose to start about 4 seconds before the sequence ends never turns on.

The same thing happen to all of the sequence were there is a initial on of the first set of channels in the sequence but then nothing. I ran the play list for 1 3/4 times thru and it looks like only one sequence made it thru correctly (named Rumble).

Please see attached output file.
Thanks,
ibby

JHinkle
12-08-2012, 02:01 PM
This issue has something to do with your computer's audio processing.

I get my timing from the audio being played.

What kind of a sound card do you have?

What version of Windows are you using?

Any thing you can think of regarding audio?

Joe

ibby
12-08-2012, 02:15 PM
Joe,
I am running XP service pack 3. The audio is built in on the mother board. It is a Dell dimension 2400 with Intel Mother board. I think it is a SoundMax Card on the motherboard.

I will try another computer and see if i get something different.

ibby
12-08-2012, 05:38 PM
Joe,

I upgraded to a "newer" pc with windows7 pro. I had to use a USB to Serial cable for the Renard. I ran my whole play list for over an hour. My observation and the debug confirm, all sequences played correctly with NO issues. The debug file just show starts and stops. I will set the debug file on tonight to see if we get the same results.

Thanks for all the hard work on this. I know it sucks when you know your application works and it is other people issues that are to blame.

JHinkle
12-08-2012, 06:05 PM
Let's just hope all is well.

Have a great night.

Joe

Henedce
12-08-2012, 08:24 PM
This is the Output plugin for Renard from Vixen 2.1.x.x
I had to change it from .dll to .txt to upload .

Henedce
12-08-2012, 08:51 PM
Just an update . Tried updating HLS and moving 1 board to comm 3 . Problem got worse

JHinkle
12-08-2012, 09:10 PM
This is the Output plugin for Renard from Vixen 2.1.x.x
I had to change it from .dll to .txt to upload .

Thanks Henedce - but I was looking for the source code - not the dll.

Joe

JHinkle
12-08-2012, 09:14 PM
Just an update . Tried updating HLS and moving 1 board to comm 3 . Problem got worse

Henedce

Are you using the 9M?

Please describe in detail what your failure looks like?

Is this NEW behavior or always been there?

Thanks.

Joe

Henedce
12-08-2012, 10:03 PM
Sequence starts no problem . At any random point the lights just stop but the music continues .
All lights off including E131 .
Did notice on one fail that some renard channels stuck on which is new .
Basicly debating now what I can loose from my display for a week while i await more digital strip .
Definitely seems to be a Renard issue . If i disable the renards the issue goes away .

Edit. forgot to add . When the next song starts everything is reset and the lights work again untill the next fail

JHinkle
12-08-2012, 11:14 PM
Henedce

Please download the special debug version of HLS using the link below.

This version will track the audio timing interface is see if something can be observed.

The issue is associated with COM ports but I don't know how/where - I'm hoping this debug will shed some light.

Please delete the prior debug file before running HLS.

Thanks in advance.

http://www.joehinkle.com/DownLoad/HLS_Install_9N.zip

Joe

Henedce
12-09-2012, 12:36 AM
Debug attached .
Lights stopped during the second last song . All E131 went off and renard froze..

JHinkle
12-09-2012, 01:11 AM
Debug attached .
Lights stopped during the second last song . All E131 went off and renard froze..

What is Tic rate for Wizards In Winter - 25msec or 50 msec

What is Tic rate for SantaClausTown - 25msec or 50 msec

Please tell me the tic rates ... one thing I'm looking at is the amount of time required for Windows to process:

1 COM buffer write
11 E131 buffer writes

The debug file show a couple of things that I don't like.

I am seeing some tics being missed - so we have a race condition someplace.


Past midnight here - I'm tired - I will investigate tomorrow.

Joe

JHinkle
12-09-2012, 01:29 AM
Henedce:

Please download 9R and run another test for me tonight.

Make the debug file available.

I added timers to measure the time required to perform the COM write and the E131 write to see if they are bogging down at some point or we have a tic over-run condition.

Thanks in advance.

NOW - I'm going to bed.

Joe

Henedce
12-09-2012, 05:31 AM
What is Tic rate for Wizards In Winter - 25msec or 50 msec

What is Tic rate for SantaClausTown - 25msec or 50 msec

All my sequencing is done at 25msec

Debug using 9R attached

Hope this helps :)

JHinkle
12-09-2012, 07:55 AM
Did this one fail?

What Song failed?

If that song played multiple times - which on failed?

Joe

JHinkle
12-09-2012, 10:29 AM
Henedce:

Please load 9T and run debug test again.

Your debug files did help - I made a change based on what I found.

By the way .... it takes 18 to 19 msec to transmit your COM package.

So .... if anyone is running COM ports ... only 1 COM universe if resolution is 25 msec.

COM is slow and there is not enough time at 25msec for more than one .... sending the number of channels you are sending.

How many channels do you have on the COM port?

Joe

ibby
12-09-2012, 12:13 PM
Joe,
I ran my show for 5 hours and debug file showed no issues. Problem solved by using another computer.
Thanks for your help!
Ibby

ibby
12-09-2012, 12:24 PM
Max Renard Channels per Wiki:

http://www.doityourselfchristmas.com/wiki/images/7/72/Renard_channel_limit.png

JHinkle
12-09-2012, 12:31 PM
Thanks for the insight.

This issue is most likely computer related ... COM related to be more specific.

E131 only playlist have been running without error for over 9 months. COM is just starting to show up as the Holiday approaches.

Problem is ... trying to figure out WHAT on the computer is causing the issue.

A lot of people feel - the issue occurred in your program - you have a problem and you should fix it.

The hard ones are when they are not under control of the program - but the program shows the behavior (as in this case I'm hoping).

Shoot the messenger!

Finding the WHY/WHAT makes it easier to say ... change this on your computer and all will be well.

Joe

JHinkle
12-09-2012, 12:35 PM
Max Renard Channels per Wiki:

http://www.doityourselfchristmas.com/wiki/images/7/72/Renard_channel_limit.png

I have not done the calculations - but those numbers may be based on RS485 bit timing - not computer time.

The computer program has to process its tasks AND make sure it gives up enough time to other processes in the computer --- that time is overhead in addition to physical message bit timing.

Joe

ibby
12-09-2012, 02:02 PM
I think 25 msec is just to short a time for serial communication, you are asking for trouble, especially when you are chaining a lot of renard controllers.

injury
12-09-2012, 02:13 PM
I just ran into the light lockup thing for the first time the other night. Been out of town so just now about to start some debugging but here is a series of actions I did before the lockup occured.

It seems to only happen on one sequence.

I was making the transition from my development computer to the show computer. The sequences were created in 8a and prior versions, the show computer was running 9D. Installed 9D on show computer and copied all my HLS stuff to the show PC. The sequence was not compiled just running in create mode with output box checked.

First several times this sequence played fine on the show PC. Then the lights started locking up in this one sequence at nearly the same spot (within a beat or two) then it seemed to degrade to way earlier in the sequence. I could stop the sequence and load up another and that would play fine but it is a bit less complicated of a sequence. Audio plays without a hitch with the lights locked up.

Some things I noticed...file size jumped drasticly compared between what was 8a and running on my dev computer and 9d and running on the show computer. Even though I hadn't changed anything on the new PC it was asking me to save everytime I opened and closed the sequences which I didn't remember happening before. When I did hit save I could no longer open the problem sequence.

Next step will be recovering the problem sequence if that fails recopying it from the dev computer.

JHinkle
12-09-2012, 03:12 PM
Hold off recovering.

Send me you HLS file - It may have an issue as I made version 9 changes.

Joe

injury
12-09-2012, 05:04 PM
Joe it blew up 90 MB's you have an ftp you want me to upload it to or something?

gassy
12-09-2012, 09:55 PM
Dang! My show has been running OK for the past week and half, last night I noticed a couple of the 'light freezes' as mentioned here. Tonight it's happening much more frequently. Do we have any idea what's up?

Henedce
12-10-2012, 04:21 AM
E131 only playlist have been running without error for over 9 months. COM is just starting to show up as the Holiday approaches.

Dont know about others but I dint even get my renard contollers out till end of November and never really used with multi channels until the night before opening night.


I think 25 msec is just to short a time for serial communication, you are asking for trouble, especially when you are chaining a lot of renard controllers.

Last year I ran 3 serial ports each with 128 channels @ 10 msec timing with no issues until I got a bad PIC which once moved to the last position on one board continued to work.

Will run the debug again tonight for you Joe , But im sure the issue will go away once my e131 to renard card arrives in the next day or so .

Henedce
12-10-2012, 06:29 AM
Latest Debug. Crash is on last song .


How many channels do you have on the COM port?
112 channels

JHinkle
12-10-2012, 07:48 AM
Latest Debug. Crash is on last song .


112 channels

Please define crash.

Error message?

Lights stop?

The debug file shows it closed the sequence after 83 time tics.

What happened?

You did not use the latest software --- my debug put the HLS version so I know what version is running.

Please do again with latest version.

Thanks.

Joe

rfallatt
12-10-2012, 09:19 AM
what was the difference between the computers I'm having the same problem

Sent from my ADR6300 using Tapatalk 2

JHinkle
12-10-2012, 11:21 AM
Please define "Same Problem".

Joe

JHinkle
12-10-2012, 11:48 AM
When in issue occurs:

We need to isolate the root-cause of the issue:

1. HLS - code that runs every time a new sequence starts.
2. HLS - code the runs every time a sequence ends.
3. HLS - code that performs illumination processing every tic.
4. Windows Driver that is involved in the transmission of data
5. Controller that receives the data
6. Controller that receives data from previous controller (daisy-chained controllers)
7. Lights
8. Computer hardware - CPU speed, Amount of Ram, Sound Card, Operating System, etc

If you have an issue - if it happens every time - THIS issue is the easiest to isolate and resolve. If it happens once in a great while - more difficult.

If it happens every time - make sure you are using the latest version of HLS. I update HLS very often - so please make sure you use the latest. I will add little breadcrumbs in the debug file to help identify the issue.

When you run your show - say YES to Debug mode - this will create a debug file holding data that will help identify issues falling into types 1, 2, and 3.

Explain the issue in detail: What song was playing and when (I need to find that position in the debug file). Did HLS provide any Error PopUp message - what did it say. Describe the behavior of the lights with relationship to the music. You can not be too detailed in telling me about the issue.

Move the debug file to another folder after you experience an issue if you ran Debug. The debug file is deleted every time you start HLS - so don't start HLS again until you relocate the debug file.

Send me the debug file and the details of the issue.

Right Now: There appears to be an issue with some people using Renard controllers.

I don't think it is everyone using a Renard which makes it difficult to isolate root-cause.

By working together and running many tests - any issue should be able to be resolved.

Joe

rfallatt
12-10-2012, 12:38 PM
Joe,
I don't have all the information right now you requested. I will when I go home.
Basically, The short story is,
I am running the latest version, (I always upgrade when prompted)
I am running Windows XP Service pack3
Problem does not happen all the time, but sporadically.
No other programs are running
I am running all Renard (8-48LSD, 2-24SS, 3-16SS)
I use 2 universes 50ms timing almost at max channels (240 universe 1, 256 universe 2)
I run directly from USB ports to RS232 (via an adapter)
Show will run sometimes for a few seconds and sometimes for longer and then lights will freeze, music continues to play.

JHinkle
12-10-2012, 08:54 PM
When the lights freeze - do they start working at the start of the next song?

What type of USB adapter are you using?

How many USB adapter do you use?

If you use more than 1 - are they the same type?

If you use more than 1 - does the complete show freeze or just channels on one of the USB adapters?

Thanks for the info - I somehow missed this this morning.

Joe

Henedce
12-10-2012, 09:51 PM
Found this today when I was looking for something unrelated. Not sure if its relevant but hey .....
Full Wiki entry can be found here http://doityourselfchristmas.com/wiki/index.php?title=Renard#Serial_.28RS232.29_Connecto rs_.28J3_and_J4.29
Special Characters

0x7D - Pad byte, silently discarded by controller firmware, inserted by host PC to prevent Tx overrun
0x7E - Sync byte, start of packet marker.
0x7F - Escape byte, used as prefix for encoding dimmer levels that correspond to the special characters.

To send the value 0x7D as data (rather than as a special character), send the two-character sequence '0x7F-0x2F' in its place.

To send the value 0x7E as data (rather than as a special character), send the two-character sequence '0x7F-0x30' in its place.

To send value 0x7F as data, send the two-character sequence '0x7F-0x31' in its place.

The PICs have a rather large internal clock frequency tolerance, which could cause a transmitter overrun in a PIC which has a slow clock. This could happen under the following circumstances:

1) The host PC is transmitting characters with one stop bit, and

2) One (or more) of the PICs is using its internal oscillator (instead of an external crystal) and

3) That oscillator is running at the low end of it's tolerance (1% slow),

The Renard firmware doesn't have any separate provision for transmit buffer other than the internal PIC transmit buffers. If data is arriving at the PIC faster than it can clear the UART transmitter, some data in the PIC transmitter would be over-written, causing data to be lost. The PAD byte is intended to give the transmitter in a slow PIC time to catch up.
Packet Format

Byte 0 - 0x7E (sync byte)
Byte 1 - Command/address byte (usually 0x80, see below)
Byte 2-n - Dimmer values (0-0xFF, values 0x7D, 0x7E and 0x7F have special encoding, all others are sent raw)

Firmware Operations

When the controller receives a character, it first checks to see if it is the sync character (0x7E). If so, this is the start of a packet, and the controller resets its packet receiving state machine. The controller re-transmits the sync byte, so that down-stream controllers can also reset their packet receiving state machines.

The next character is the command/address byte. There are three possible cases for this byte:

1) If this byte is less than 128 (0x80), it is for some protocol that this firmware cannot handle (reserved for future use). The command/address byte is retransmitted, as are all the remaining bytes in the packet.

2) If the byte is exactly 0x80, the next eight bytes (after decoding) are intended for this controller. The command/address byte is retransmitted. The next eight bytes are decoded and used internally without retransmitting. The remaining bytes in the packet are retransmitted for use by the downstream controllers.

3) If the byte is greater than 0x80, the packet is intended for some downstream controller. The command/address byte is decremented and transmitted, and the remaining bytes in the packet are retransmitted.

JHinkle
12-10-2012, 10:46 PM
Thanks for looking - that was implemented into HLS back in Feb 2012.

Are you using a USB to COM adapter?

Joe

JHinkle
12-10-2012, 10:57 PM
I believe anyone reporting the Renard COM freeze issue - also states that the lights work again when the next song starts.

To me .... that is a very important observation.

HLS closes the port at the end of the song and opens it at the start of the next song.

That fact suggests the issue is either in the Window's driver that takes COM requests and then communicates with the USB dll OR in the USB's dll. Either way - the closing and opening of the port resets the process and it can continue to work.

I don't like USBs that are viewed as COM ports - it adds a layer of code and reduces performance. I would always rather talk directly with the dll.

I will extend HLS's USB Transport to include a COM protocol.

HLS will then talk directly to the USB dll ... one hitch .... it has to be the FTDI USB dll.

You will need to match 32 and 64 bit OS with the 32 and 64 bit FTDI dll.

I will release this capability tomorrow and I NEED PEOPLE TO TEST IT!!!!

If those of you that have your COM communication freezing and this new USB interface resolves it ... then we are home free.

Please let me know who can test this on Tues 12/11.

Thanks.

Joe

rfallatt
12-10-2012, 11:18 PM
I can test, with some assistance (by phone possibly) best time later in the evening 8:30EST.
How do I check if my I can test.
I may be able to get away sometime (an hour or two) in the day time

Henedce
12-11-2012, 02:07 AM
That fact suggests the issue is either in the Window's driver that takes COM requests and then communicates with the USB dll OR in the USB's dll. Either way - the closing and opening of the port resets the process and it can continue to work.

I dont use a USB to Comm.
My boards are plugged directly to Comm 1 on the motherboard.

If this resolves the USB side thats great . Dont spend to much time on mine now as I have a D2 coming from J1Sys so will be running all E131 soon :)

Again thankyou for your time and patience trying to resolve this issue.

Henedce
12-11-2012, 05:36 AM
Use FIFO buffers = unchecked.
Could the answer be this simple ?

Nope still same issue

JHinkle
12-11-2012, 07:41 PM
Version 10D is released.

I suspect the "Freeze" issue is the Window's USB driver or the supporting DLL.

10D now provides the option for you to NOT use the USB Virtual COM port but have me talk directly to the FTDI dll.

So ... your USB adapter MUST have the FTDI chip.

You need to ReCompile your sequence for Export. Do nothing else except recompile --- SHOW schedule etc all stays untouched.

Select Transport COM. Select Protocol RENARD_USB. Select the COM port that specifies your serial communication characteristics ... note - you can assign ANY COM number between 1 and 20 ... they are for your reference and will NOT be used in any Windows call.

Select the FTDI device that will be your COM device.

From then on ... the device drive you loaded with your USB adapter is out of the transmission path. I'm hoping THAT is were the issue is for you folks having a COM/Adapter freeze issue.

For now ... if you compile on one machine and then move to a SHOW machine - take the USB adapter with you. I have code that will detect a missing adapter and ask for a replacement but have not fully tested that path out yet.

Please try the RENARD_USB protocol and report back with a Debug file and your result.

Thanks.

Joe

gassy
12-12-2012, 08:20 PM
Hey Joe,
The Renard_USB didn't help me with the wireless setup I'm using. After our discussion the other night, I believe you are correct in speculating that the board I'm using for transmitting with the X-Bee is being 'choked'. Tonight it was 'freezing' on every song. I knocked the channel count down in each sequence from 160 to 104 and now everything seems to running OK. I'm going to hardwire everything until I can find a 'good' board to use with the X-Bee (Anyone have a suggestion?) I have the debug reports if you're interested. Thanks for all your help.

Henedce
12-13-2012, 03:26 AM
My problem solvered.
Got my ECG-D2 today plugged it in and bingo no more crashes .
For the US$64.00 delivery in 2 days + 1 simple cross over cable , I should have just gone this way from the first errror.

Joe again Thank you for trying to debug this.
I look forward to working with HLS even more now :)

JHinkle
12-13-2012, 08:36 AM
With the help of Joel doing nightly testing for me --- the issue is resolved.

Version 10G has the bug fixed.

Joe

rfallatt
12-13-2012, 09:15 AM
Joe
Do you mean... the issue is resolved and people are able to use USB to serial adapters on the com ports an it works? or ... the issue is settled that USB to serial adapter do not work for hi channel and data content ?

Sent from my ADR6300 using Tapatalk 2

JHinkle
12-13-2012, 09:23 AM
I was going to contact you and say TEST the cheap USB/COM devices again and see what happens.

I found a bug and fixed it ... it may verywell have been the issue you had since Joel was just now able to generate a debug file that contain the data I need to see the root-cause for MOST freezes.

Please let me know if your USB adapters work.

Joe