Hello!
Yes, I know that running PcVue in multi-instances is not a good idea.
But I have a big project which uses more than 230'000 var on a single serial port in Modbus-RTU.
In this condition, CIMWAY won't start due of high number of frames, see article KB102.
So I have suggested to this customer, "as last chance", to split the data acquisition between two separated PcVue instances.
The problem now is at the startup of the 2nd instance, when another PcVue instance is running. I have this error:
CIMWAY, Start operation error : CwReadConfiguration() : 125
Start Cimway : Error copying protocole in .BinTmp directory (125)
Do you know a way to solve this problem?
I know that this solution is not very "elegant", but it's a complex situation with an Italian OEM so I cannot propose better solutions without changing their architecture.
PcVue version is 9.0 Build 1318
Thank you very much!
At startup pcvue copy the cimway DLL but in your case the DLL is already in the temp folder due to first instance.
You can wait for MAnu Duval answer or send him an email, I think it's one other good reason to avoid multiinstances.
Maybe be you can suggest your customer another architecture based on multiple active server.
...230'000 var on a single serial port in Modbus-RTU...
Is it a joke?
Did you customer surprised that it's not working well?
As said by Romain he should split in at least 2 servers...
No... unfortunately it's not a joke!
It's a project coming from GEWISS, an italian OEM that use PcVue for emergency lighting supervision.
They've realized an external configurator that automatically "build" our .DAT files (VAREXP, COMM & mimics) based on an automatic-discovery over the "network" (serial port...). :sick:
This is a big hospital and they have a lot of emergency lamps (about 10'000) with a lot of tags for each of these. The result is 230'000 tags in only 1 serial port!! :sick:
The customer doesn't absolutely want to modify his project from PcVue because he don't want to lose the compatibility with the external configurator.
So we have agreed that the only possible solution is to split these lamps over two different serial lines and run 2 PcVue instances on the same station.
I'm going to ask Manu Duval if he know the way to allow Cimway working in this condition! 🙁
Hi All
I discuss with Filippo and we agree that:
NEVER tell a customer that multi instanciation is possible!!! This is an in-house trick ONLY
The customer project has 36 equipments and lots lots of frames.
New driver have no limit in the number of frame it can handle but old one such as Modbus RTU has a limit and his customer reached it.
To know if you run an old or a new driver refer to the protoc.dat file.
If the driver you are using is PROTOCOL,XXX,10, it is an old one
If the driver you are using is PROTOCOL,XXX,20, it is a new one
Luckuly for Filippo we wrote a while back a new version of the Modbus RTU (it is deliver in the bin of PcVue under CwpXbusNG.dll.) It is never used (for fear of compatiblity reason) but in his case we simply modify the protoc.dat file so that his project start this new driver and now the project start correctly now.
As for the update of the data we cannot do miracle but at least we can pool all the equipment with no frame limit.
Happy end !!
Yes, infact! Thank you Manu for your trick!
I want to add just for future reference an information told me by Manu yesterday. Infact very often the message:
"CIMWAY, starting communication error: CwReadConfiguration(): 103
Start Cimway: not enough memory (103)"
appear also when the COMM.DAT file is not correctly filled even if maximum nodes/frames limits are not reached.
I think is useful for diagnostic.
Thank you again and please correct me if I have writed something wrong.


