TOPIC:

This is a bug...

Another thing that PascalSCADA does, is the tag grouping. If you put 3 tags, with address 0,1,2 AND the protocol supports the read of multiple registers, it will do a single request to read the registers 0,1,2.

Another thing that PascalSCADA does (by default) is the continuous read. This means that the protocol will read the tag with more time elapsed from the last read, ONLY IF the protocol will do nothing on current scan. If one or more tags was timed out, it will read only these tags. To disable this feature (and read only timed out tags) set the property ReadSomethingAlways to false. Your bus activity will be decreased a lot.

Yes, it's a good name for HMIEdit property . I understand now. Thanks. Forgive me , I'm a beginner .
Earlier i aslo try my program with one HMIEdit linked with a tag set FrezeOnFocus=false. But after You sugesst I add the second HMIEdit, only then PascalScada began communicate, and only with virtual com port driver ( virtual com ).

this configuration still not working: (PascalScada <-->Moxa RealCom RS-232)< -cable->( RS-232 <-> Simulator)
I still can send value to the simulator, but i can't read this from simulator
papelhigienico wrote:

This is a bug...

So, if this is a bug, is there any chance to fix that problem?
Thanks for Your answers

papelhigienico wrote: Another thing that PascalSCADA does, is the tag grouping. If you put 3 tags, with address 0,1,2 AND the protocol supports the read of multiple registers, it will do a single request to read the registers 0,1,2.

Yes, I saw it on the monitor communication . It's very good option.

set the property ReadSomethingAlways to false. Your bus activity will be decreased a lo

Yes I did, still does not work.

Guys
we uploading now LAB CT 5.2 (rev 005131) with pl_PascalSCADA with source from 26-11-2014 SVN Rev 912

But I'm not sure if anyone reported a similar problem, and the new version will it work?

Hi Mr. sternas!

Do you have a radar for "bug" word???

Good, the current revision has a initial support to on screen keyboards, some bug fixes and new controls.

I'll fix this bug of THMIEdit on pascalscada repository soon as possible. I have two critical bugs to fix before, since that this bug on THMIEdit affects only the usability.

swicio1 wrote: Yes I did, still does not work.

Maybe I don't see, but Can you post the log of this communications that don't works?

papelhigienico wrote: bug on THMIEdit affects only the usability.

This is not only THMIEdit. Also THMIlabel can't tead from PLCTagNumber1.
I tried to read the value directly from PLCTagNumber1 eg. on Label1.Caption and also nothing, gives a value of 0

Sorry, here is the logs:

Yes we know that
components icons are NOT the best...
(screen from Typhon64 for Win64)


and we fix some pkg installation problems on FreeBSD and MacOS X (look at attach)

from pl_PascalScada ctinfo.txt
=========== MODs ==============
database\pscada_dbreg.pas ### at line: 4
hmi\crosskeyevents.pas ### at line: 133
hmi\crosskeyevents.pas ### at line: 173
hmi\crosskeyevents.pas ### at line: 178
hmi\crosskeyevents.pas ### at line: 282
hmi\customizedusermanagement.pas ### at line: 29
hmi\customizedusermanagement.pas ### at line: 31
hmi\customizedusermanagement.pas ### at line: 32
hmi\customizedusermanagement.pas ### at line: 33
hmi\customizedusermanagement.pas ### at line: 39
hmi\customizedusermanagement.pas ### at line: 41
hmi\hmibasiccolletion.pas ### at line: 3
hmi\hmiobjectcolletion.pas ### at line: 109
hmi\hmiobjectcolletion.pas ### at line: 135
hmi\winccusermanagement.pas ### at line: 4
scada\scadapropeditor.pas ### at line: 218
scada\serialport.pas ### at line: 833

Thanks! I can't wait

Looking at your logs, everythings is ok. The data request sent by PascalSCADA is received by your simulator AND the simulator reply to PascalSCADA. The same happens when you write a value from PascalSCADA to your simulator.

Look these lines:

gru-02 18:23:19.095, iocWriteRead, Result=iorNone , Written: 01 06 00 00 03 0A 09 3D
gru-02 18:23:19.095, iocWriteRead, Result=iorOK , Received: 01 06 00
gru-02 18:23:19.095, iocRead , Result=iorOK , Received: 00 03 0A 09 3D


If I'm not wrong, using Modbus function 06, the answer of a successful write is a copy of write packet command. Can you give me a screenshot of your simulator? I'm suspecting that are you looking to another register table. This happened to a friend on last week, (he was not using PascalSCADA) due a confused Modbus documentation.

If I'm not wrong, using Modbus function 06, the answer of a successful write is a copy of write packet command

Yes, is a copy of write packet command.

papelhigienico wrote: Looking at your logs, everythings is ok. The data request sent by PascalSCADA is received by your simulator AND the simulator reply to PascalSCADA. The same happens when you write a value from PascalSCADA to your simulator.

Look these lines:

gru-02 18:23:19.095, iocWriteRead, Result=iorNone , Written: 01 06 00 00 03 0A 09 3D
gru-02 18:23:19.095, iocWriteRead, Result=iorOK , Received: 01 06 00
gru-02 18:23:19.095, iocRead , Result=iorOK , Received: 00 03 0A 09 3D

Yes, i see, but in Result, first line is "Result=iorNone". In correct communication is "Result=iorOK"
Then i can see in HMIEdit or HMILabel value from simulator.

In CT 5.20 is the same problem with MOXA.

avra wrote: From your logs, sending 01 03 00 00 00 01 84 0A from PascalSCADA to MOXA results in a timeout, and sending the same 01 03 00 00 00 01 84 0A directly results in valid response. From this I have a conclusion that PascalSCADA tries to send the same thing both times, so it's not a problem with PascalSCADA. What you should do is to try to send the same sequence with moxa and directly, using some terminal software both times. You can also try free MODPOLL command line software and report results. Your claim that other SCADA software supports MOXA means nothing if it was confirmed in some other environment, and not exactly yours (running PascalSCADA application and some other scada application from the same pc, using same cabling to plc, testing one after another). There may be many other things, but I suspect cable problem, baudrate too high (try lowering speed if PLC allows), and no or wrong RS485 termination (if you use RS485 on PLC side).

@swicio1:
You didn't use terminal to send 01 03 00 00 00 01 84 0A modbus message to simulator and report response received here. You didn't do the same thing with MOXA too. You didn't try MODPOLL program as suggested. You didn't report baudrate. You didn't try another cable.

Well, how many people with byte level knowledge of MODBUS protocol do you think will read your message in this forum? When someone who can help for free asks you to do something you should better do it, or otherwise that someone will stop helping.

Sending a raw message with terminal directly first to simulator and then to moxa and reporting response will tell us all if these devices are responding to MODBUS messages as they should. Maybe moxa returns something unexpected? Maybe your simulator has some bug, have you tried another one? Even connecting terminal on both cable ends would tell you if messages are passing through with or without errors. We could all see that if you just did what I said. Also using MODPOLL program to read some registers from simulator or moxa will potentially give us success or error messages that could further help. Also running 38400 or higher baudrate on 7m cable will most probably give communication errors, so I would like to know if you are using 9600 or what on this 7m cable? Also, when you have non-isolated cable grounding may matter a lot and introduce communication errors. Is grounding connected on both cable ends? Does cable connect only RX and TX, or it connects also shield and other pins? Do you have the same problem when using laptop running on battery and not connected to power supply? Do you use exactly the same serial port comm settings in software used on both ends of the cable (something like 9600N81 or similar - but it must be the same on both ends)? Does the same problem happen with simulator if you use virtual 2 comm ports tunnel instead of cable?

Well, if you ignore these suggestions once more I wish you luck since I will not look into this thread again...

@avra, I'm sorry , You're right.
I will do everything You sugest me tommorow (I'm sick today) and will raport every communications sets and other necessary informations.
I am grateful that you want to help me.

EDIT:

@avra,
I have one question about MODPOLL command line software - it's working as a modbus master( if I'm not mistaken). PascalScada is working as a master too.
Should I use Diagslave Modbus Slave Simulator form modbusdriver.com? Or find another software?

Put a TTIPropertyGrid (RTTI palette) and link it with your tag (TTIPropertyGrid.TIObject=YourTag). Put too into your form a TTimer and put this on OnTimer event:

TIPropertyGrid1.RefreshPropertyValues;


to force update on property grid. The next step is run your application and see the value of properties LastAsyncReadStatus and, after write some value, the value of property LastAsyncWriteStatus on your TIPropertyGrid

swicio1 wrote: I have one question about MODPOLL command line software - it's working as a modbus master( if I'm not mistaken). PascalScada is working as a master too. Should I use Diagslave Modbus Slave Simulator form modbusdriver.com? Or find another software?

Yes, MODPOLL is free modbus master command line software. I use many free and commercial MODBUS tools, but this one is the reference for them all. It has never let me down. You should kill your PascalSCADA application, then try to read with MODPOLL the same register you wanted to read with PascalSCADA from the same simulator you used initially. You will have to set MODPOLL settings properly. For that you will have to read docs and use -h parameter. You repeat the same using some terminal software (I usually use Bray++ Terminal or HTerm) which can send raw bytes instead of MODPOLL and send raw bytes mentioned earlier. These two actions give us 2 reports. Then you put terminal software on both sides of the cable and report if you see echo chars on both sides without errors. Then you repeat test with another simulator (like www.modbustools.com/modbus_slave.asp which should run fine for some trial period if I remember well) and we have 2 more reports. Then you replace cable and see if there is any change. Then if there are still problems (or you don't have another cable) you repeat all this with virtual comm ports (like Eterlogic Virtual serial ports emulator). Then you repeat all this with MOXA and PLC. It is important to have exactly the same settings and environment as when you reported PascalSCADA having comm problems, and just replace one and then the other side of communication with test software. Depending on the results of first tests you might not need to do all mentioned tests, or you might need to do new ones, but this is basically what you need to do to find out where is the problem - using systematic elimination. In all reports you need to give as much details about master and slave as you can (OS, serial port settings, if you use USB to RS232 convertor, if you use RS485, cable, exact MOXA model, all settings from MOXA port configuration, exact PLC model, explain or draw if connection path is complex...).

You should also read again my previous messages in case I have forgotten to mention something.

I hope you are also aware that when you want to access MODBUS RTU server through SERIAL => ETHERNET convertor you need to use MODBUS RTU protocol no matter of a fact that TCP is used for tunneling it to virtual moxa driver based comm port, and that if you want to access MODBUS RTU server through MODBUS RTU => MODBUS TCP gateway you need to use MODBUS TCP protocol. In both cases proper device parametrization is crucial. There is also non-standard and rarely used MODBUS RTU over TCP (or UDP) but that is of no use in your case. If you use wrong one then there is no communication at all...