Using ActiveXperts Serial Port Component with HTML forms on a client PC. ActiveXperts Serial Port Component is a software development kit (SDK) that enables the user. Another way could be virtualizing your serial ports using a rs232 to. Not able to display the received data in textbox from serial port in the C# web.

I want to design a webform that user should fill some fields. The value of one field should be read from Serial port (COM1) of client computer which a special hardware is connected to it and the user presses the Send to PC key of the hardware when filling the form. How i can listen to COM1 port in my webpage and get the value of COM1 and place it in the web form automatically? I heard that ActiveX controls can do this but it is compatible only with IE (right?). The other option is Java applets. I want a simple solution which be compatible with (at least) IE/Firefox/Opera.

I the server-side i can have ASP or PHP but i am appreciate if you give a solution for each. UPDATE: We can tell clients to change their security settings to accept our ActiveX/applet. It is also possible for us to tell clients to install a custom program which runs as a service and reads from Serial port.

The problem is the read data should be entered to the webform automatically and immediately. The java applet is a good idea, but the client have to install JRE which is large in size. Convert Dmg To Iso Virtualbox Linux on this page. Is there any other option?

Hello Suthakar. No offense meant: yours is a bit of a strange question. Let me explain: ASP.NET (MVC or WebForms) is for Internet and Intranet applications. Serial port communications are generally for talking to attached devices: modems, various hardware that can interface to a computer (example, a gasoline fuel pump's computer captures quantity and fuel card information that can be input and sent to an accounting package). So, I'm curious as to the nature of your application. In answer to your question, it depends on the capabilities the device with which you happen to be communicating. You need to give the documentation for that device and then determine what you options are with it.

Example: likely most modern modems can send half duplex and full duplex. Which mode is better likely depends more on the nature of the developer's application than on the merits of half duplex versus full duplex. Rule of thumb (general): if the developer needs to make decisions based on input line content, likely character input is preferred; OTOH, if the developer is processing input records, likely line based input is preferred. To better respond to your question, imo, you need to give us many more details. Sorry, your question is just way too general.

You need to clarify it for the rest of us. Regards, Gerry (Lowry). I do not see what this has to do with the ASP.NET paradigm. I think you may be mixing ideas here. I'm not sure what you're trying to achieve.

Example: ASP.NET MVC or WebForms (a) a page request is received (b) ASP.NET application displays that page and goes back to sleep (c) GET or POST comes back from page displayed by (b) (d) ASP.NET application responds appropriately and goes back to sleep. Et cetera ---------------------------------------- serial port processing (i) local application starts and negotiates connectivity with serial port. (ii) local application runs constantly, no sleeping, and continuously listens to serial port. ---------------------------------------- Here is what you should read to meet your serial port listening needs: also: suthakar i have got Data_received event occurs in windows application.

Can u guide me for asp.net application. All you can do AFAIK is to store your data in your ASP.NET MVC Model until a user requests it by clicking a submit button. Alternatively, your web page on your end user's computer could continuously request updates using Ajax. Ajax example tutorial: #39 Iteration #7 – Add Ajax functionality View in or Regards, Gerry (Lowry). You can not have what you want per se. You need a multi-tier architecture because the hardware that talks to the external GSM modem via the serial port must be physically connected to the external GSM modem. Therefore: (A) external GSM modemserial port[web_server].

[web_client] (B) external GSM modemserial port[data_layer_computer][web_server]. [web_client] (C) external GSM modemserial port[data_layer_computer]. [web_client] =. Physical connection. TCP/IP connection suthakar, please study the above three architectures.

Remember, physical devices without wireless connectivity must be physically connected to whatever computer needs to communicate with the physical device. Suthakar, you are talking about architecture (A).

(A) external GSM modemserial port[web_server]. [web_client] Earlier in this thread, I showed you what to check out: Here is what you should readto meet your serial port listening needs: also: If you want to purchase someone's SKD, it's probably safe ~~ I would ask them for references from their existing customers. You probably do not need an SDK from a third party. Also, the manufacturer of your modem should have documentation to help you. You have at least two options: do it yourself; hire a specialist. Suthakar, in your previous post, you said the modem was connected directly to the server. I do not understand.

There is more than one way to do it are your clients in the same room as your server? A remote client computer can capture information from its serial port and then send it via FTP to the server. Are you trying to do something in real time????? Is this simply aggregating data for reporting purposes? I really do not understand what you are trying to achieve. That makes it difficult for anyone to answer your question.

Perhaps you can explain your design goals, your design constraints, and your physical architecture in more detail? Suthakar, if all of your computers are in the same facility, then the diagram is not relevant.

They can simply drop tiny files on the server and the server can aggregate them. Alternatively, the server can have a local application that they talk to via your network constantly. If your server is remote, you can still have similar scenarios as above by using VPN connections. VPN will be slow but FTP will be slower. You could possible create some form of web service on your server and have your local PCs talk to that service.

You need to simplify your application into two or more separate parts. E.g.: one component would gather the serial data, another component would worry about how it gets that data to the server; the server component would deal with aggregating the data. Hey Gerry - I read this thread and I think I may be trying to do something similar. I am writing a kiosk application that will be web based - C#, VS2008. The kiosk is an IBM Anyplace kiosk that has an MSR (magnetic stripe reader) physically attached. The MSR is configured to work on COM3 - 19200, 8, N,1.

I wrote a quick little desktop app using the serial port listening objects in.Net and I was able to detect the card swipe, parse out the mag stripe and display the contents in a sampe form. I'm now trying to do the same thing on an aspx page that will be displayed on my kiosk. The page is simple - it displays a graphic asking the person to swipe their credit card. I understand that once the.aspx page is loaded it is now client side, and that.aspx pages normally cannot communicate with hardware due to security restrictions. I've got a call out to IBM to see if they have any Java objects that might fit the bill. In your experience do you have any idea how I might accomplish this? Asp.net C# 3.0 com port listening web page • •.

@ fcrombeen: One guess: write something like an ActiveX control as a bridge between your web app and your MSR. I'm curious: 'a kiosk application that will be web based'?????? Since a kiosk is a physical computer, there is AFAIK zero need for it to be web based; I would write it a a standard desktop application and use something behind the scenes from the TCP/IP suite of protocols to use the Internet as a back end. Depending on security, some kiosks should be on private networks and not on the Internet; a typical example is a bank card terminal know as an ATM (automated teller machine); for all intents and purposes, an ATM is a kiosk.

Browser-serialport Robots in the browser. Just like but for browser apps.

Why not Node.js? Are awesome but HTML5 apps have access to a lot of APIs that make sense for robotics like the,,, etc.

Also you get a nice GUI and its easier to run. I have also made a fork of to work with as well by modifying it's dependancy to use browser-serialport. Restrictions You will not be able to add this to your normal website. This library only works in a as this is the only way to get access to the in the browser.

Incidentally, since (a.k.a. Node-webkit) now fully supports the Chrome Packaged App platform, this means you can also use this library in NW.js v0.13+. If you want help making your first Chrome App, read the tutorial.

There is currently no Firefox extension support but that might come soon if possible. Known incompatibilities with node-serialport • Parsers not implemented • Inconsistent error messages • Chrome has a slightly different options set: • dataBits: 7, 8 • stopBits: 1, 2 • parity: 'none', 'even', 'mark', 'odd', 'space' • flowControl: 'RTSCTS' Installation. } ); When opening a serial port, you can specify (in this order).

• Path to Serial Port - required. • Options - optional and described below. The options object allows you to pass named options to the serial port during initialization. The valid attributes for the options object are the following: • baudrate: Baud Rate, defaults to 9600. Should be one of: 115200, 57600, 38400, 19200, 9600, 4800, 2400, 1800, 1200, 600, 300, 200, 150, 134, 110, 75, or 50. Custom rates as allowed by hardware is supported.

• databits: Data Bits, defaults to 8. Must be one of: 8, 7, 6, or 5. • stopbits: Stop Bits, defaults to 1.

Must be one of: 1 or 2. • parity: Parity, defaults to 'none'.

Must be one of: 'none', 'even', 'mark', 'odd', 'space' • buffersize: Size of read buffer, defaults to 255. Must be an integer value.

• parser: The parser engine to use with read data, defaults to rawPacket strategy which just emits the raw buffer as a 'data' event. Can be any function that accepts EventEmitter as first parameter and the raw buffer as the second parameter.

Note, we have added support for either all lowercase OR camelcase of the options (thanks @jagautier), use whichever style you prefer. Open event You MUST wait for the open event to be emitted before reading/writing to the serial port. The open happens asynchronously so installing 'data' listeners and writing before the open event might result in. Nothing at all. Assuming you are connected to a serial console, you would for example.