ANVIL API (Assent) Developer Thread

API version: 2.6.7.66

I was running Anvil.exe
- 2.6.7.87 and
- 2.6.8.16


I guess Getting an API with the current version & getting the ANVIL.exe (debug) hopefully i'll be on my way to actually getting connected

 

1) When I downloaded the initial Anvil platform I noted that the download was Anvil_2_6_8_16_Release.msi. I'm assuming this is not want I want I want the debug version.

I asked Assent about this. They sent me an AnvilDebug version

when I click Anvil.exe I get this error...


C:\Documents and Settings\Administrator\Desktop\AnvilDebug_x32_2_6_7_4\Anvil.exe
This application has failed to start because the applicatoin configuration is incorrect. Reinstalling the applicatoin may fix the problem.

 

Has anyone ever experience the current Anvil Time changing in the middle of the day in sym mode?

I just changed my application so that it processed the data from Anvil in a separate thread and it appears to work great. The only problem is that both times that I ran it this morning about a half hour into running it the Anvil Time changes.

So this morning I started running it at 9:30 (at which time the Anvil Server time was 9:30). The app ran fine until 9:54. At this time the Anvil server time all of a sudden changed to be 2:50 AM).

I started running it again at 10:06 (at which time the Anvil Server time was 10:06). The app ran fine until 10:36. At this time the Anvil Server time all of a sudden changed to be 3:38 AM).

 

I never seen this issue. Thanks for the warning ....

 

ctarmor,

In your applications do you make all of the B_ calls in your main thread?

I'm wondering if the reason I'm experiencing the problem with the Anvil Server Time changing on me is because I call many of the B_ methods within my worker thread.

 

Yes, the main thread. I define WM_* messages to perform actions on the main thread.

Worker threads post these messages onto the main thread ..... my hook in the main thread processes the WM_ requests ....

 

You can appear to "get away" with making some of the B_ calls in your worker thread, meaning everything will appear to work most of the time. But the calls aren't thread safe, so this is a risky procedure and I think you should avoid it.

When I programmed my first implementation, I was making several of those calls from my worker thread. It worked great until I started to increase my number of symbols into the thousands, then I started seeing weird errors... As would be expected from non-thread safe routines. You start to get statistical failures, and increasing the sample size increases the probability of detecting a failure. I use basically the same method as ctarmor-et, i.e. ALL of my B_ calls are in the main thread, without any problems.

I'm sure it's unrelated, but I'll just mention it here in case someone else comes across the same thing: One bug that I have noticed is that if you let Anvil run for several days at some point you will start getting the wrong timestamps for prints coming from the summary server. This usually happens in the morning when Anvil reconnects to the servers (all of the timestamps for the prints will be from the night before, even though the prints are coming in in real time). I solved this problem by restarting Anvil daily.

 

tj, How do get the right time out of the prints ? My routine seems to be showing a few seconds difference ?

 

Are you processing the M_SYNC_TIME message? It provides the server time and you can use that to create an offset to adjust your local time.

Code:

case M_SYNC_TIME:
{
	FILETIME ftLocalTime;
	FILETIME ftServerTime;
	static LONGLONG llOldDifference=NULL;
	LONGLONG llDifference=NULL;

	GetSystemTimeAsFileTime(&ftLocalTime);

	SystemTimeToFileTime(&((MsgSyncTime *)pMessage)->x_SystemTime,&ftServerTime);

	llDifference=*((LONGLONG *)&ftServerTime)-*((LONGLONG *)&ftLocalTime);

	TRACE("M_SYNC_TIME message received.  Time difference:  %i\n",llDifference-llOldDifference);

	// Only update the time if it is before 7 am.  Otherwise, this creates problems.
	if(((MsgSyncTime *)pMessage)->x_SystemTime.wHour<7)
		if(m_pFeed)
		{
			m_pFeed->SetTimeOffset(&llDifference);
			llOldDifference=llDifference;
		}

	break;
}

In the code above, m_pFeed is a pointer to my class where I process the prints, etc.

I don't change the offset in the middle of the day, because it screws up the relative time between prints. That's what that comment refers to.

But I believe that some timestamps are generated by the server and transmitted TO the API, and some timestamps are generated upon receipt from the server BY the API... So it might make sense to use the offset in some situations, but not in others. I'm not really sure.

For example, I've been told that the print timestamps received from the summary server were generated by the server... But due to the bug that I've observed, it makes me wonder if this is true or if instead they're being generated by the API.

 

Thanks for the detailed response. I do not process the sync message but I will look to see if I need to ....