Hi Chris, You are correct regarding the handling of the RACK / SLOT for the connection to the S7.
For example for a high availability connection (S7400H), you have two CPUs in different Racks, being able to lift two connections to the same system. Connection #1 PC (Rack 0, Slot 1) -> CPU Master (Rack 0, Slot 3) Connection #2 PC (Rack 0, Slot 1) -> CPU Slave (Rack 1, Slot 3) On the PC, the slot number is due to the fact that the communications card is placed in a virtual rack (Siemens way). So it is a good idea that both parameters (local & remote) can be manipulated by the driver. Best regards, El jue., 9 de enero de 2020 1:48 p. m., Christofer Dutz < christofer.d...@c-ware.de> escribió: > Hi all, > > I think today I had a breakthrough which explains quite a bit of issues we > saw in the wild. > One was that someone suggested to swap where the rack and slot values were > used … initially we used them in the calling-tsapid and not the > called-tsapid. > Now it seems as if every device has its own rack and slot value … so > instead of just having “rack” and “slot” we should have “local-rack”, > “local-slot”, “remote-rack” and “remote-slot”. > Currently the remote rack and slot were hard-coded to 0 … it seems the S7 > doesn’t care what you pass in as local-rack and slot, but it instantly > hangs up if you provide the wrong remote-rack and slot. > Sort of like when you call someone, the other picks up and the other side > hangs up as soon as you ask for the wrong person. ;-) > > What do you think? It does sort of make sense. > > Chris >
