hschir Posted June 26, 2012 Share Posted June 26, 2012 I persistantly receive the following message in the Command/Alert window C1038 Timing Lag, data acquisition stalled. Resetting Timing: 1.000, Offset: 0.000 I have 10 analog input channels set at: Timing 1.00 Offset: 0.00 I have a further 9 channels reading values from a modbus gateway set at: Timing 10.00 Offset 0.00 the reason for the modbus gateway timing setting is that the gateway updates the gateway register data at 10 second intervals. Currently the C1038 messages appear about every 3 minutes. I have tried everything I can think of to isolate the problem - but am at a loss now how to proceed any further. Any thoughts ? PS - my ctl file is too large to upload. Link to comment Share on other sites More sharing options...
AzeoTech Posted June 27, 2012 Share Posted June 27, 2012 Timing lag means that the system was not able to keep up with the desired polling rate. In your case, its with the channels with Timing = 1. Apparently it is taking slightly longer than 1 second to poll all 10 input channels. To eliminate this error you'll either need to decrease your polling rate (increase Timing), or figure out how to make your hardware faster, for example by blocking your tags if that is an option. Link to comment Share on other sites More sharing options...
hschir Posted June 27, 2012 Author Share Posted June 27, 2012 I assume that by "blocking your tags" you mean the DAQConnect tags ? If not - what do you mean ? Link to comment Share on other sites More sharing options...
AzeoTech Posted June 27, 2012 Share Posted June 27, 2012 No, DAQConnect has nothing to do with it. By blocking your tags I am referring to Modbus. I don't know what you are using, but if you are using Modbus and you can arrange your tags so that they are in order (i.e. channel #1, 2, 3, etc for U16/S16), then DAQFactory can make one query instead of multiple queries which is much faster. Link to comment Share on other sites More sharing options...
hschir Posted June 27, 2012 Author Share Posted June 27, 2012 Ok - My Modbus configuration in the order thay appear in the channel table is as follows: n.b. all having timing set at 2.00 TAG I/O Type Chn# V01_degC Read Holding S16(3) 6 V02b_m_s All others: Read Holding U16(3) 8 V02_m_s 7 V03_deg 9 V04_R_mm 28 V05_ET_mm 31 V06_RH 18 V07_hPa 3 V08_IR 25 V09_mm 23 Link to comment Share on other sites More sharing options...
AzeoTech Posted June 28, 2012 Share Posted June 28, 2012 The order in the table doesn't matter. If you can make deg_C U16, it will help slightly, but then you won't be able to measure below 0C presumably. As for the rest, do you have any control over the locations? If so, move them so they are all in a block. If not, consider adding some dummy channels for at least 24,26,27,29 and 30 and maybe even 19,20,21 and 22. Just call them dummy24, dummy26, etc. or whatever you want. You don't have to do anything with them, but by telling DF you want to read those channels, DF can make a single query for channel 18, requesting 14 registers. Right now, reading those tags above 18 takes 5 different requests. Do the same at the low end, especially if you make degC U16 (or make the others S16? I don't you'll overflow 15 bits for those tags unless there is a scaling factor). That'd mean adding dummy tag 4 and 5. Then you'd be down to two requests to read all your tags instead of the current 8 requests. Link to comment Share on other sites More sharing options...
hschir Posted June 28, 2012 Author Share Posted June 28, 2012 THnaks for that ... I don't really need to read below 0 degC so I can change that tag to U16 and leave all others at U16 as well. I see what you mean with the dummy tags. DF can read them but I don't necessarily need to do anything with the data. Link to comment Share on other sites More sharing options...
hschir Posted June 29, 2012 Author Share Posted June 29, 2012 Thankyou ... That seems to have solved those issues. Now have one other problem. I regularly keep getting: D0050:01:1008 LabJack Device #1 error: Communications failure Sometimes it is LabJack 2 (I'm using 2 LabJacks using wifi) ? Link to comment Share on other sites More sharing options...
AzeoTech Posted June 29, 2012 Share Posted June 29, 2012 Are you using D# 0 with one of your LabJacks? You can't do that if you have more than one since 0 means first found, and its possible that the first found is the same ID as the other D# you are using. Link to comment Share on other sites More sharing options...
hschir Posted June 29, 2012 Author Share Posted June 29, 2012 No - I'm using D# 1 and D# 2 ... Link to comment Share on other sites More sharing options...
hschir Posted July 2, 2012 Author Share Posted July 2, 2012 I think I've solved my comms failure alert - seems that my wifi signal is low and packet losses might account for the issue - relocating the wifi repeater for better signal strength appears to resolve that problem Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.