Delphi Xe Serial Port Component Speakers
- Delphi Xe Serial Port Component Speakers Bluetooth
- Delphi Xe Serial Port Component Speakers Ebay
- Delphi Serial Port Component
Gratis Serial Port component for Delphi XE8 or Lazarus IDE. Ask Question Asked 1 year, 10 months ago. Active 1 year, 10 months ago. Viewed 98 times 0. The Windows Standard Serial Communications Library for Delphi (WSC4D) is an serial communication library based on the Windows API. Includes 52 functions plus modem control, serial comm API. WSC4D uses the core Windows API to communicate with any device connected to a serial port from within a Delphi application.
MarshallSoft Delphi serial communications component library for RS232 and multi-drop RS485 and RS422 serial ports. Use WSC4D to write applications to access data from serial devices such as barcode scanners, modems, lab instruments, medical devices, USB serial devices, scales, GPS navigation, fingerprint scanners, printer servers, etc. Features of WSC4D include: - Supports 256 ports. DesignIDE package and porting Delphi 7 components to Delphi XE2 HI I am porting components from Delphi7 to Delphi XE2, and started run in problems regarding MaskProp.dcu, some of the components uses this, and is looking for TMaskProperty class. After a lot of browsing on the net i figured out that all these units is packaged in the designide.dcp.
- You can program it to read from/write to the serial port that the FTDI chip on the Arduino interfaces with. You can (I presume) write applications using Delphi to write to/read form the specified serial port. If you specify the one that the Arduino is connected to, you can make Delphi talk to the Arduino.
- MarshallSoft Delphi serial communication component library (DLL) for serial port communications. Uses the standard Windows API to communicate with any device connected to a serial port. Includes 32 functions plus modem control, ANSI emulation, ASCII/ XMODEM/ YMODEM protocols, hardware and software flow control, and multiple Delphi example programs.
- ZylSerialPort is a Delphi / CBuilder thread based asynchronous serial port component. Use ZylSerialPort component to easily communicate with external devices on serial port connection, such as modems, bar code readers, GSM modules and others.
For a long time I have used the SerialNG component provided by Domis
(http://www.torry.net/authorsmore.php?id=3670), and I was able to get it to
work well for my application, but I had to do some tricky coding, such as
setting a critical section, and saving incoming data to a separate buffer
which was then used for error checking and data processing. It is an
integral part of two of my products, and sometimes I still get errors, but
they are more likely caused by the USB serial port driver. I'm using a
Silicon Labs CP2103 USB device.
Now I am working on another project, and I'm just reading a string of
comma-separated text data with CRLF after each line. The line is about 30
characters and I'm transmitting at 9600 baud, 1 stop bit, no parity, and no
flow control. These lines are transmitted every 300 mSec. I was able to use
Hyperterm to verify that the data can be received and displayed accurately.
Hyperterm is a problem on Win7 because you can't reload the HT files and
must re-enter the communication parameters, but that's just an annoyance.
But when I made a simple terminal program using D4 and the SerialNG
component, I would get errors where it would miss characters and even entire
sequences, and I was able to get some improvement (or break it completely)
by fiddling with the cluster size and receive character timeouts. I was
parsing the incoming data and using the memo.strings.add method to display
each line when I detected a CRLF. So I thought maybe it was unsafe to do
this from the receive cluster event processor. The demo seemed to work, but
it is not a simple terminal and it also displays data as hex, with a
date-time stamp.
So, I downloaded and installed ComDrv32
(http://www.torry.net/pages.php?id=198), and confirmed that its terminal
demo received and displayed the data properly, and I incorporated it in my
program and it works perfectly well, without any 'fiddling'. I had a few
problems installing the component and I had to restart D4, but then it
seemed to compile and run fine.
Does anyone have experience with either of these components? Or recommend
another? I may try a new version of my Ortmaster application with the
ComDrv32 component. If I can do it more simply, I will be happy. KISS is
wonderful!
Thanks,
Paul
The TComPort component was originally written by Dejan Crnila, it was modified a bit by other people, including me, among others. It didn't need much tweaking, other than a bug fix here and there, and support for new Delphi versions as it came along. The latest version 4.11b is available on SourceForge here.(http://www.torry.net/authorsmore.php?id=3670), and I was able to get it to
work well for my application, but I had to do some tricky coding, such as
setting a critical section, and saving incoming data to a separate buffer
which was then used for error checking and data processing. It is an
integral part of two of my products, and sometimes I still get errors, but
they are more likely caused by the USB serial port driver. I'm using a
Silicon Labs CP2103 USB device.
Now I am working on another project, and I'm just reading a string of
comma-separated text data with CRLF after each line. The line is about 30
characters and I'm transmitting at 9600 baud, 1 stop bit, no parity, and no
flow control. These lines are transmitted every 300 mSec. I was able to use
Hyperterm to verify that the data can be received and displayed accurately.
Hyperterm is a problem on Win7 because you can't reload the HT files and
must re-enter the communication parameters, but that's just an annoyance.
But when I made a simple terminal program using D4 and the SerialNG
component, I would get errors where it would miss characters and even entire
sequences, and I was able to get some improvement (or break it completely)
by fiddling with the cluster size and receive character timeouts. I was
parsing the incoming data and using the memo.strings.add method to display
each line when I detected a CRLF. So I thought maybe it was unsafe to do
this from the receive cluster event processor. The demo seemed to work, but
it is not a simple terminal and it also displays data as hex, with a
date-time stamp.
So, I downloaded and installed ComDrv32
(http://www.torry.net/pages.php?id=198), and confirmed that its terminal
demo received and displayed the data properly, and I incorporated it in my
program and it works perfectly well, without any 'fiddling'. I had a few
problems installing the component and I had to restart D4, but then it
seemed to compile and run fine.
Does anyone have experience with either of these components? Or recommend
another? I may try a new version of my Ortmaster application with the
ComDrv32 component. If I can do it more simply, I will be happy. KISS is
wonderful!
Thanks,
Paul
Like a lot of developers who need to do serial communication, I started using Turbo Power's very capable AsyncPro product, which is still alive, and doing well. I have said some negative things in the past about AsyncPro, because the complexity in it mixed poorly with the complexity in my products, and when I had to debug things, I found it really hard to debug AsyncPro. But I should introduce a policy here on Delphi Code Monkey; I intend to publically do penance for stupid things I have said in the past. AsyncPro is a fabulous component set, and nothing negative I have said in the past should be held as more correct than the simple fact that lots of people use, and still use AsyncPro, and are happy with it.
Nevertheless, as a person who believes strongly in the 'smaller is beautifuller' concept, almost to an absurd degree, and who has found that the less code I put in my application, the less my application breaks in horrible ways, I still prefer TComPort for the cases where I need to do serial communication in a delphi app.
TComPort seems like exactly what I needed for my purposes. So what were my purposes? I wrote applications that did the following things:
Delphi Xe Serial Port Component Speakers Bluetooth
1. Talk to industrial or scientific or laboratory equipment, over an RS-232 or RS-485 link. Some of this equipment including Programmable Logic Controllers, using a common protocol called 'Modbus RTU', or simple Ascii (text based) serial protocols, some with, and some without checksums. For modbus capable PLCs, I wrote a descendant component that does Modbus client communications, for Delphi, that can talk to a wide range of industrial and process control, and scientific equipment that implements this protocol.2. Talk over a direct cable link, or a modem link, to equipment at a remote site. This is incredibly powerful. One application I wrote in the mid 1990s had dialup remote control of an emergency power grid that could be remotely activated by the power utility company in a major midwestern US city, whenever the grid needed additional capacity.
Here are things that I didn't need TComPort to do, things that would make AsyncPro a better choice than TComPort:
3. I did not need a full featured 'video terminal emulator' that did fifteen different terminal emulations, including a reliable VT-52, or PC ANSI terminal emulation. You might need this, if you had to connect to an old computer system that provided serial terminals.
4. I didn't need to use the file transfer protocols from the BBS era, that include XModem, and ZModem.
Back in the DOS and BBS days, long before the Internet, those of us who used to 'go online' used to do so using DOS programs called 'Terminal programs', and plastic boxes called 'modems', that let your plain old phone line talk at incredibly high speeds, between 300 and a few thousand bits per second. Just about everything that you could do in Telix, you can do in AsyncPro. AsyncPro (formerly from TurboPower, now open source) is better than TComPort, if you need a full featured video terminal emulator, or x/y/zmodem file transfers. If you still wanted to write a Telix for Windows in Delphi, Async Pro would be perfect for you.
So having given AsyncPro its due, let me proceed to why I like TComPort:
A. Small, Fast, Light.
B. Simple thread and event model.
One common place that serial ports still show up these days is in the IT world. Sometimes you might have a network router, or VPN box, that has a serial terminal that you might want to talk to. At one of my old workplaces, we had a building alarm system that had a serial port cable. We logged the alarm activity on our servers, using a little capture program, originally in VB, which I rewrote in Delphi.
Just because.
Delphi Xe Serial Port Component Speakers Ebay
If you want to drop a component on a form, and talk through a serial port, check it out. Your programs can remotely interact with, control, or supervise a wide variety of equipment out there. You could even attempt to write the Auto-Dialer that figured so prominently in the 1980s movie War Games. Please don't hack our national electrical grids though, or I will have to hunt you down and give you a wedgie. Also the CIA and FBI might want to talk to you. Be good. Thanks.If you have problems with this component, you can talk about it on the forums on sourceforge, and we'll try to help you out.