Ethernet is Fun......Not

[flopro 0]

Make sure S:2/15 is not set in the Channel 1 status file. If it is then only one communication request is serviced per scan. You can also "sprinkle" SVC instructions in the ladder logic to force the SLC to do some unscheduled communication request servicing on either comm channel. Usually you want to control these SVC instructions with an XIC S:2/5 (incoming command request pending) or S:2/7 (outgoing command request pending). After doing this to a SLC 553 with 3 PV600's, RSView32 and RSSql the Ethernet network became so "snappy" that the customer's operations personnel thought the control system had been replaced. It had been sluggish for 3 years and PV's had hold times on the buttons and interscan delays extended unnecessarily. I observed through RSLinx driver stats >80 packets/sec. servicing RSView32 and RSSql OPC topics. Remember, there are 3 PV600's also on this network performing discrete batching operations for three production areas besides RSView32 and RSSql. In PLC5 platforms you don't have the SVC instruction but you can adjust the S:71 time-slice in ms to let the PLC processor have that much more time to perform housekeeping routines between scans; communication requests being one of them. Just be aware that this additional time is added to the overall scan time. Edited 23 Dec 2007 by flopro

[paulengr 44]

Here, we're getting into representational details. Averaging has a tendency to smear out details when in fact you may be interested in the peaks. max() and min() catch peaks but may obliterate the overall trend. Subsampling kind of takes a middle road between the two and has the advantage of being fastest but the amount of computation to do the others vs. subsampling really isn't that great. There are also several other algorithms out there for dealing with multiscale data that have the goal of trying to preserve certain details of the dataset at the expense of others. This specific feature is something that I'm aware exists in at least a couple of the data historian databases out there. Since it's not generic SQL (and neither are any of the historian databases), you're walking down the road of highly proprietary applications.

[Nathan 7]

I have. I tried doing a "WHERE index MOD interval = number" on the primary key. Alternatively you can create a temporary table for this. In both cases it was slow. I'm guessing that it was running a hash table instead of a binary tree. I didn't spend much time investigating. There may be more suitable data structures on the tables that speed this up. Holding and reading ordered client side datasets in memory is a really cheap operation. A large query may take a lot of time, but zooming/scrolling on the data should be really fast. In my experience querying the larger set of data and having the graph decide which points to display (you mentioned several methods) is often quicker than trying to query for that same subset of data directly. It's certainly orders of magnitude faster when you decide to zoom/pan on the result. The thing is that your data point time intervals need to be within reason for this to be possible. The worst operation will be the large query - smaller ordered intervals on that data will be fast. So if you can bound your largest data range to an acceptable time you're good. The trick is really in choosing your logging interval.

[enigma 0]

@flopro "Make sure S:2/15 is not set in the Channel 1 status file. If it is then only one communication request is serviced per scan" I just checked this and all slc505's on the network have this bit set = 1. Would this cause the problem??? Interesting point. Can it be that easy??

[flopro 0]

Yes, it can be this easy and you'll be a-frigging-mazed! If I recall correctly, S:2/15 will impact the system dynamically and immediately by toggling it while online with RSLogix500 using the status file GUI. Remember to consider the other part of this 1-2-punch; the SVC instruction(s)... Edited 28 Dec 2007 by flopro