|
you have asked a similar question before and received an answer. Continue to use that thread, don't create new one.
How do you expect a user to see and use 100,000 point on a chart in the first place?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Thanks for replay
Mark Nischalke wrote: How do you expect a user to see and use 100,000 point on a chart in the first place?
User can view the report. After generating the report chart points based on the performance.
it will send back to browser. so threading is not feasible one because otherwise every request we generate a points. want to send back entire value at once.
|
|
|
|
|
I missed the previous thread..
Can you give more information about the data? A sample data set would also help enormously. I hope it's not floating point coordinates - the techniques necessary to compress that are quite complicated.
Is 1MB really too big, though? It doesn't sound so big to me..
|
|
|
|
|
Don't send a million points, or even 10,000. A graph will be at most 500 pixels across, so if it's timeseries type data (only one Y value per X) then you need at most 500 points. Filter the points that get sent back so there are enough to view a nice graph, and don't send everything.
The TCP stream should already be compressed with modern hosts and browsers. But sending a megabyte in response to an AJAX call is not good netiquette anyway.
|
|
|
|
|
hi
is it be better to open connection to database -
make any querys...update....delete -
and after i use to close this connection
or
open the connection when the program load -
and close when the program close ?
thanks in advance
|
|
|
|
|
this gets asked at least once a week around here.
the answer was and still is: open-use-close at the functional level (i.e. within a single method), not at the application level.
database connection licenses are expensive so you shouldn't have them sit idle, and connection pooling will reduce the technical cost of opening and closing connections.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: database connection licenses are expensive so you shouldn't have them sit idle
Depends quite a lot on the licensing model
|
|
|
|
|
Right. But then, the licensing model can always change, so better be safe than sorry.
And if expensive things aren't allowed to sit idle anymore, we would have problems with managers, bankers, politicians, and more.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
|
Don't be expensive. Close the connection when ever your process is over!! 
|
|
|
|
|
MOST of the time (but certainly not all of the time), close your connection between database calls. If you're going to make several subsequent calls one after the other, close it after the last one.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
This depends on the application. If you have simple database tasks, closing and reopening is fine. But if you have several calls to the database in a single unit of work and you need (as you should need) transactions, you must keep the connection open at least to the end of the transaction.
Another point is that if you use notification mechanisms from database to the client, you'll need an open connection in order to receive notifications.
|
|
|
|
|
|
Hi all,
I'm seeking some quick tips to how to send and receive commands and data to/from a handheld device via a serial port. I've been handed the device (not your common off the shelf device but a specialised bit of kit) and a pdf with technical details of packet structures, i.e. Preamble, packet header, packet data.
The packet header is borken down into sections of consists of TYPE, SIZE, DSUM, HSUM.
TYPE - the command type, i.e. 0000 = Ping Connection, 0001 = Disconnect, 0101 get data, 0801 rest device etc...
SIZE - the size of the packet data
DSUM - Data check sum - addum sum of all bytes in data section to the checksum seed 55 (power of 16?)
HSUM - Packet header check sum - adding summ of all byte values in the packet header to the same seed value
Basically, where do I start? I also need to take into account timeouts etc.... Can I use standard .net libaries or best to purchase a 3rd party library?
Andrew
Andy
|
|
|
|
|
>> DSUM - Data check sum - add sum of all bytes in data section to the checksum seed 55 (power of 16?) <<
Am I right in saying that when the doc states check sum 5516 displayed next to it in a small font, the 16 refers to 16 bit?
I'm learning the hard way and not even started to look at coding anything in c# yet.
Andrew
Andy
|
|
|
|
|
sorry my earlier reply got lost. I asked the CP staff whether they could recover it somehow.
yes, a subscript of 16 would normally indicate hexadecimal notation, so 5516 would be 85 in decimal.
_awatts wrote: not even started to look at coding anything in c# yet.
then IMO a serial communication app is not a good choice, as it can be tricky at the application level even for an experienced programmer.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Thanks for the reply, simply confirming 5516 represents 16bit makes this document alot clearer.
If my packet structure is as follows
Preamble
SYNC - Word - A55A16
Packet header
TYPE - Word - 010116
SIZE - Byte - (data size)
DSUM - Byte - Data checksum using 5516 seed
HSUM - Byte - Header checksum using 5516 seed
Packet Data
Start - Byte - data[0]
Data - Data[...]
Am I therefore looking to create an array of bytes, the first 7 bytes for the Preamble and Packet header. Therefore the first two representing SYNC [A5,5A], the next two representing TYPE [01,01], the following byte holding the value for SIZE (number of bytes taken up by data), then the byte holding the value for DSUM, then the byte holding the value for HSUM. The 8th byte will hold a 0 (start of data), any bytes from here on holding the data?
If so, how do I calculate DSUM and HSUM?
Regards,
Andrew
Andy
|
|
|
|
|
_awatts wrote: how do I calculate DSUM and HSUM?
Haha, excellent question. There are hundreds of checksum definitions, some of them are standardized by ISO or by CCITT. And I could come up with a few that probably haven't been used yet... Your best hope would be it is described in the documentation. Failing that, you would have to ask the other party, or experiment by collecting a few short messages with correct checksum, then running them against all kinds of known checksum definitions until you find a match for each of the test messages.
Warning: yes a word seems to be two bytes in your context, however you also need to know which byte comes first: the high-value or the low-value (known as endianness: big-endian versus little-endian). Just looking at the start of a correct message (a SYNC word) should tell you.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Many thanks for your quick response and help.
Having never written a comminications program and based on your feedback I seem to be heading the right direction. I'll do what you've suggested, analyse a respose from the device in terms of packet size and structure, and try out a few different check sum methods to see which one yields the same result. That is if the device will send some data without having to raise a request to the device.
Again, thanks for your help.
Andrew
Andy
|
|
|
|
|
Some more ideas:
1. You're obviously an optimist. Any small mistake you will make while implementing some checksum algorithm is bound to go unnoticed and will output a non-matching value for sure.
2. If the device doesn't give any packets by itself, you could again look in the documentation, maybe there are examples.
3. If it is a commercial device, there is bound to be some PC software for it, so using that one could get it to work, then observe the packets that are going back and forth on the cable. If such software were managed code (e.g. C#) you could even use a tool such as Reflector to peek inside it.
4. You can of course look at incoming packets and ignore their checksums if you choose to do so. The data still would be useful most of the time; the checksums are there to protect you against communication mishaps that would yield false packets.
5. You probably do need to provide correct checksums when sending data to the device, although I have met a few systems that accept an "I don't care" value too, which always has been zero in my experience. Note: I do not recommend serial communication without some kind of protection, I'm just pointing a possible and temporary approach that could get you started. Does the documentation state what the device will do when it gets a packet with a bad checksum?
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
>>2. If the device doesn't give any packets by itself, you could again look in the documentation, maybe there are examples<<
Unfortunatley no examples. I'll try and contact the company who made the device.
>>3. If it is a commercial device<<
Nope. A specialist device only used within the healthcare industry. Previous version written in VB compiled as a Win32 app. I've been tasked to write a replacement without original source.
Andy
|
|
|
|
|
_awatts wrote: Previous version written in VB compiled as a Win32 app
So you can still run the device and observe actual good packets? That is good.
BTW: you should insist on good documentation! You did pay for the device, didn't you? So demand quality docs.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Go to this link and read the answer of that question.......
I think it will solve your all problems...........
|
|
|
|
|
Following is the general way to interact with your COM Port
try
{
sp.PortName = "COM1";
sp.BaudRate = 9600;
sp.DataBits = 8;
sp.Parity = Parity.None;
sp.StopBits = StopBits.One;
sp.DataReceived += new SerialDataReceivedEventHandler(read_data);
sp.Open();
sp.Write("AT" + Environment.NewLine);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
|
|
|
|
|
I've never had to do this before, and it's a Monday so my brain is not all here yet. I did try google first, but found nothing very helpful. I have a form application that can be started directly or via commandline passing a parameter, however, I need to debug the code in VS when I start it via commandline. What is the best way to do this?
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
