Recent

Author Topic: [SOLVED] USB connected device- How to access 'Bus Reported Device Description'  (Read 1391 times)

bobby100

  • Full Member
  • ***
  • Posts: 100
    • Malzilla
You have SerialPortDriver component in your project?
Take a look at the events of the component in Object Inspector.
https://gitlab.com/bobby100 - my Lazarus components and units
https://sourceforge.net/u/boban_spasic/profile/ - my open source apps

https://malzilla.org/ - remainder at my previous life as a web security expert

Username

  • New Member
  • *
  • Posts: 22
Thanks Bobby100,
I'm looking at the responses now and comparing to the RTU Protocol Specifications. Can't believe I didn't even check the SerialPort Events. Geez.  %) Big help. Much appreciated!

Username

  • New Member
  • *
  • Posts: 22
When I do an intentional write error, (Value out of range or non-existent memory address) I can see the output in the error log file and it has the expected values returned by the device.

However, neither of the error events of SerialPortDriver are triggered. I have them set to activate, but they are not triggered, and I don't see how to check the Device response after a write operation. I looked into the SerialPortDriver routines and I can see where I could hack it to get the result but I don't want to do that and have to do all the licensing stuff required for modifying the libs. Surely there's a simple way to check the responses?

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1559
You can also look at the LastSyncReadStatus of a TPLCBlock after trying to read some info from your device.
Code: Pascal  [Select][+][-]
  1. if (ReadStatus<>TProtocolIOResult.ioOk) then ErrorHandling;

bobby100

  • Full Member
  • ***
  • Posts: 100
    • Malzilla
SerialPortDriver can detect just the communication errors (bit parity check does not match and such). In real life, this is the layer where you'll get the 90% of the possible errors.
As for ModBus protocol, the master is sending a package and the slave responds to the master with (almost) the same package.
This is probably not visible in PascalSCADA, as it should be a background process.
Setting values outside the range - it should be programmer's duty to take care of.
You could ask Fabio about the details of error handling implementation.
On www.pascalscada.com, in the documentation section, you can ask questions (every documentation topic has its own discussion at the bottom of the page). Fabio usually answers in a couple of days.
https://gitlab.com/bobby100 - my Lazarus components and units
https://sourceforge.net/u/boban_spasic/profile/ - my open source apps

https://malzilla.org/ - remainder at my previous life as a web security expert

MarkMLl

  • Hero Member
  • *****
  • Posts: 4737
I am /so/ glad that @Bobby100 has volunteered to answer that... :-)
MarkMLl
HA! I don't usually write LOL but I am! Very funny.  ;D

The reason I was unhappy is that your question could be read as assuming predictable behaviour on the part of an unknown Modbus slave or other attached device. TBH, for things like this I don't even like assuming that an isolated read of a contact doesn't in some way change the state of a slave (I've seen people do pretty weird things with PLCs... please don't ask).

Even if the question relates strictly to experimentally opening a serial port and immediately closing it without writing data, you never really know- in the general case- if that's visible to attached equipment. For example, does opening a port ackle either DTR or DSR, and is something Arduino-like attached to it that treats a DTR edge as a reset? Alternatively, what is the behaviour if that port is already in use but without exclusive access?

Windows booting used to have a lockup problem since by default it would look at each serial port in case a mouse was attached. Unfortunately all it did was ackle RTS (?) and look for CTS to track it, and if it saw a modem it accepted it as a mouse.

The moral is that if you don't know that it's "your" port, don't touch it. Or at the very least, tell the user what's happening and how to recover. Which is a good argument for using e.g. FTDI device serial numbers (or something equivalent), provided that the OS allows these to be read without opening the port.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018