2 Questions: Timelines - and - buffer data

DigiMe

To All:

Does anyone know how many active timelines can be running at any given time? I have a few timelines in each of my modules and several instances of these modules implemented. My understanding is i can reused same timelines inside a module and not worried about a few times lines running with the same ID. It works fine until I implemented the last module and regardless if I connect over IP or RS-232. The device is a BiAmp AudiaFlex.

I thought it might be an issue in my data receive timeline, so I removed that event and put my data parsing back into the Data_Event: String.

2nd question:
has anyone received in there buffer this: "e.class"

This is a debug string:

DEV-1024:1 :: DATA :: Sending To fnParseRcvData() -> e.class
DEV-1024:1 :: DATA :: Sending To fnParseRcvData() -> e.class
DEV-1024:1 :: DATA :: Sending To fnParseRcvData() -> e.class

initially, i was receiving this strings will my data parsing was in a timeline:

(0000146643) DEV-1024:1 :: DATA :: Sending To fnParseRcvData() -> $01$F8p
(0000146893) DEV-1024:1 :: DATA :: Sending To fnParseRcvData() -> $01$F8p
(0000147143) DEV-1024:1 :: DATA :: Sending To fnParseRcvData() -> $01$F8p

here is my timeline:

timeline_event[tlDataRcv]
{
if(find_string(devinfo.buffer,"$0D,$0A",1))
{
stack_var char thisDATA[512];

thisDATA = remove_string(devinfo.buffer,"$0D,$0A",1);

set_length_string(thisDATA,length_string(thisDATA) - 2);

fnDebug(nDbg_Lvl3,"'Sending To fnParseRcvData() -> ',thisDATA");

fnParseRcvData(thisDATA);
}
else
{
timeline_kill(tlDataRcv);

fnDebug(nDbg_Lvl4,"'Timeline "tlDataRcv" Has Terminated'");

clear_buffer devinfo.buffer;
}
}

this was constant, even though i was was not querying the device nor was the device sending data back to me. I even did a hard disconnect and i was still receiving data supposedly, once again either over IP or RS-232.

I did not have any for loops or whiles so it is not like it is retaining the data from the buffer because I am not pulling it out. In fact, if the buffer has data in it, but is missing the delimiter of "$0D,$0A", then I would clear the buffer out.

This is a ghost in the machine and I need help to get it resolve.

Thanks all,

rfletcher

this was constant, even though i was was not querying the device nor was the device sending data back to me. I even did a hard disconnect and i was still receiving data supposedly, once again either over IP or RS-232.

I'm not sure if I'm reading this correctly, but it sounds like you're getting string data events even when you're physically disconnected from the device. Is that correct?

ericmedley

I would assume that as long as the timelines in the modules all have unique TL integers, you shouldn't have any issues running multiple timeline. However, if you're defining the timeline id inside the module and not passing it through by reference, all bets are off.

In other words, if the TL ID is always, say 11, then there will be collisions.

As to the number, perhaps engineering could junp in. I've ran several timelines at once without a hitch. (several being 10s)

I'm not wanting to drift off topic, but I never do any data parsing in a TL myself. I keep my use of them pretty strictly for timing stuff. I've found most async communications to be, well async. From what I see, you're not really using multiple steps in the TL ( switchc(timeline.sequence) ... case 1: case 2: etc...) So, in essence you're just putting some parsing routines in an event you can fire when needed. So, why not just go ahead and put that in a function? Just a thought...
e

DigiMe

individual device modules have unique timeline IDs such as a projector module as to a switcher module. However, instants of using the same module, one for each of the same type of device, then the timeline IDs are identical. I have not had an issue with this since, as an example, I am running 10 projector modules of the same device, and so each one will have an identical timeline ID as to the next projector. The same is true with my LCD modules, or my switcher modules.

This is one device with its unique timeline IDs, not like any other, and it is giving me a fit. The module structure is pretty much identical as to any other module, other than strings and such. I have gone up and done looking for logical errors and have not come up with any visible issues.

Side note - the timeline is only executed when a data_event - string comes in, then the timeline runs, and as long it finds the prerequisite delimiter, then it will parse out the data, other wise, it will kill the timeline and clear the buffer. This way, the timeline is not constantly running, but I am not missing out on buffer data........well in theory at lease. Nothing is perfect, especially in the world of AMX.

PS. has anyone seen the issue as to the second question?

Joe Hebert

ericmedley wrote: »

I would assume that as long as the timelines in the modules all have unique TL integers, you shouldn't have any issues running multiple timeline. However, if you're defining the timeline id inside the module and not passing it through by reference, all bets are off.

In other words, if the TL ID is always, say 11, then there will be collisions.

That's not true. I never pass a timeline ID into a module. A module can have a timeline ID declared in the module and you can have multiple instances of the same module without issue. I do it all the time.

ericmedley

Joe Hebert wrote: »

That's not true. I never pass a timeline ID into a module. A module can have a timeline ID declared in the module and you can have multiple instances of the same module without issue. I do it all the time.

Well, that's good to know. Thanks! I just assumed it would and went with it.
e

DigiMe

My Bad -- Rookie Mistake

Well, ignore my questions. Though I was referencing my buffer to find the prerequisite delimiter, I was referencing my stack_var when running the remove_string() function, and not my buffer.

IE:

stack_var char thisData[512];

thisData = remove_string(thisData,"$0D,$0A",1);

when it should have been:

thisData = remove_string(devinfo.buffer,"$0D,$0A",1);

"Oh how one can stare at a line of code and not see the obvious."