Hi Ergunov,
Okay, I go to the trouble again and try to clarify this. Let's go.
I've read your post three times and the only thing I can found is that you are mentioning nearly the same things like I do, only with more detailed information on top.
Zitat
I repeat once again Railcom and Railcom Plus are one and the same standard,
Physically yes, no doubt from my side. And ofcorse it has to be, because otherwise this wouldn't work on the same technically way like it is descibted in the tech.doc. (read my former post, I explained exactly this with the 1st/2nd OSI-layers)
But again you look on Railcom from a technical point of view. This isn't the view from an end user. If it would be like you claim, then it would not matter what kind of hardware the end user buys. Railcom or Railcom+ products, he always gets the full functionality because Railcom is always the same - and finish.
I'll try to explain with an other excample from former times. DCC is a normed and standardized protocoll since many years, but what happened as the protocoll was expanded for the long adresses? The DCC protocoll with the long adresses also was included into the DCC normation. Why? - Yes, because it should technically remain the same (again refer to the low OSI-layers). Otherwise there would have been compatibility problems ...
Now, what was the situation for the end user?
1) If he/she starts from zero and wanted the extention with the long adresses, he/she was only allowed to buy components that already supported this feature.
But you could have also buy components that did not have this extension. So, for the end user there were two "DCC-protocolls" although it was technically the same and was written into the normation.
2) If he/she already had DCC hardware, these users felt the difference very clearly. I don't think I have to go on here. ...
Zitat
The fact that Railcom requires special equipment is of course obvious, it cannot be otherwise.
No doubt, I've written the same.
Zitat
Regarding the compatibility and problems of different equipment.
It's not so simple.
At the moment there are 4 feedback blocks supporting Railcom: (We do not take into account OpenDcc and BIDIBI)
1. ECoSDetector RailCom - firmly attached by EcosLink to Ecos.
2. Blücher GBM16XL - absolutely redundant in current in the circuits, has a very high final price. Half of the RailCom implementation, only Channel 1 works.
3. Roco Z21 detector Railcom - the same problem as Esu is tied to the CAN bus, which allows you to work only with Z21.
4. Digikeijs DR5088RC - LocoNet bus removes restrictions and allows you to connect the module to different stations, work with the DR5000 and Z21 has been confirmed. In fact, it can work with any station with LocoNet; the main condition is that the station supports OPC_MULTI_SENS packets.
Here I think you know more than I do, especially more details. But I definitely agree with you that there are these compatibility problems and that is why Railcom is not always the same for end users. Like I already wrote here:
Zitat
The Railcom hardware you can get on the market not always does support Railcom in the same extent. There are several differences on the available hardware although the Railcom sign is printed on.
Ultimately, the Railcom standard serves as the basis for Railcom to function in principle. ...
Zitat
I do not understand what kind of connection problems you are talking about.
Where did I speak of connection problems? I didn't mention anything like that.
Zitat
Explain to me the fool how POM will work without RailCom., This is not physically possible.
Multimaus does not count, so there is actually no POM, but only an imitation.
Wait, I can't accept that, whether immitiation or not, the pure programming on the main track is possible. Just not the reading of CV's.
And:
[quote="Rainer Lüssi" post_id=2074089 time=1581054084 user_id=225]
PoM works by sending config values to a specific decoder address. That works completely without RailCom and with devices such as the Marklin CS2 (no RailCom present).
The limitation in this case is changing the address.
[/quote]Thanks to Rainer.
Zitat
z21 which does not have a separate exit to ProgramTrack can POM, and RailCom is in it.
POM programming works when accessing a specific address, for this reason it is not possible without Railcom.
Yes, thats true.
Zitat
The standard is accepted, there are devices. So far, one obstacle is the greed of manufacturers who are doing everything for RailCom to work only when using their infrastructure.
Yes. Well, another thing I have already mentioned.
Zitat
About the costs agree. But what are the costs. Almost all decoders introduced in the last 5-8 years have Railcom support. Stations and boosters also support it. We need feedback blocks with Railcom, they are really more expensive than ordinary ones, ...
Again, you explain in more detail what I wrote.
Zitat
... and of course the question of compatibility between different manufacturers is open.
Yeah, the compatibility "problems" I also mentioned before.
So it's beyond me how you can ask this? ...
Zitat
What compatibility issues are you talking about? I don’t understand. I have never experienced anything like this.
Zitat
If you are offended by quoting your message, I apologize. It was simply one of the last and one of those where a lot of questions were raised. I used it not for you personally, but simply as one example.
No, problem at all. The only thing is, you claim that Railcom has to be viewed in a total different way but you say exactly the same things like I do in almost all aspects.
Zitat
In general, I agree that there are enough problems with the implementation of RailCom, but this thing is interesting and has future even in our computer age.
Here I am definitely with you. A bidirectional communication leads to a lot great features and possibilities.
Zitat
Maybe when the requirements of RCN become more stringent with regard to their compliance, then RailCom will work with equipment of any manufacturers.
I can only hope so. Then compatibility problems can also be excluded
Zitat
Vinc and another question.
Did you yourself have experience with Railcom, or are all your arguments “paper” and based only on data from the Internet and your assumptions?
Just why am I asking this, I myself had a lot of questions and doubts, some of which were decided and dispelled only when I "felt" RailCom live.
I on my personal track, no. However, in our club and with some friends. Problems here and there, sometimes easy to solve and sometimes it is very tedious to find the reason for errors at all.
Some problems have been because of hardware from different manufactures, some because of combination of older hardware (15 or 16 years old, no age for model railroad conditions) with newer ones.
... Fortunately, we are 3 electrical engineers in the club.
Best regards,
Vinc