Whats NEW in 1.070 versus 1.052 ? (Example VIDEO and JPG)

Hello. I change firmware of my commander from 1.052 to 1.070, but i cannot find out difference or corrected errors. A lot of errors remains the same + some new bugs were added.
Please, place at forum full list of changes.

Also, You can see at this clip (link below) my automatical train movements(my draft layout) after bug removal, and also can see that imagination of occupancy by red and traces by yellow color is so errorneous (time of clip: 09:00)

http://www.youtube.com/watch?v=c4hxSwWe8Vw

And there is my sheet(photographed using panorama imaging
[Blockierte Grafik: http://img-fotki.yandex.ru/get/5001/vadimav.4/0_46650_49911a2_XL]

----------
Thanks,
Vadim

Are there anybody who knows list of changes for 1.070 firmware?
-------
Thanks,
Vadim

Zitat von MuggelClan

Hello Vadim,

following news and improvements have the Version 1.070:
Improvements:
- Optimized program structure
- Improved Performance of the Viessmann SpeedBus / example: Registration of the LSB devices at the Commander with new structure
- Optimization in Updater and routes editor.
- mistakes- / removal of an entire row of small bugs

and new backup program.

Alles anzeigen

Ok. I closely work with routes and route editor.
But i detect some new errors:

1)For example - confusing in commands (switching ) page. if this error occurs, ater then some turnouts starts as not reacting at commands during automation and by manual swiching , Moreover: these turnouts are not imagining after confusion at diagramm, and starts imagining by another symbol at route/commands page . The nature of confusion i cannot still detect.
This error was abscent at 1.050

2)Imaging of busy(red) and trace(Yellow) routes is not correct during automation. Some busy parts remains bysy even after release(red). This error was abscent at 1.050.
In addition, further trace imagining on diagramm (yellow) during automation dont imagine at new parts of diagramm when You shift the virtual screen.

And main disadvantage - 1.070 HAVENT MORE SPACE FOR COMMANDS, ESPECIALLY IN "ON THE WAY" PAGE (there are only 3 pairs !!! ).

---------
Vadim

Zitat von John Ferguson

Dear Vadim

I have also found bugs since installing version 1.070. If you use Google translator you should be able to read this.

1. When setting routes and selecting turnouts and transfering to the track plan, the turnout indicator does not always change when operating the turnout.

2. The turnout icons in route index card 4 are not always correct. To obtain the correct icons you have to save again every turnout included in a route.

In addition a bug from previous versions is that if you alter the position of feedback sensors in the track plan they still show red in their previous position.

I think that the Viessmann team should issue a new update to correct these bugs within the next 4 weeks as I feel that the investment we have made in purchasing this expensive DCC controller merits a priority upgrade.

While existing owners find these bugs very frustrating new oners could take the view that the Commander is faulty and should be returned for repair.

Regards

John

Alles anzeigen

Yes. I agree. This slow progress all because Viessmann has side group of programmers from another company, and feedback between Viessmann and this company is too slow. As a solution, i already told Viessmann Head and J. Meier - to make Viessman internal programmers group. But they still dont answer me about it. If they dont rapidly create this group, they risk to fail!

ESU and other groups already plan to do automation in their trottles. They will use
traincontroller-like algorythms in aim to dont invent bike itself.

---------
Thanks, Vadim

Zitat von John Ferguson

Dear Vadim

Again you can use Google translator to read the text as I have no German.

That was very interesting information about the arrangements for system development.

It seems to me that the Company has a superb product but it is damaging it's reputation by not having the experience to enable it to manage the development. The fact that these obvious bugs are there shows that the beta testing regime is not all that it should be.

I am waiting for Jurgen Meier to report back on the system development plan for the next two years. He promised to consult the management.

I have a web site where I intend to report regularly on the progress with the system including the progress in dealing with the bugs.

see:-

http://www.electrorail.co.uk

You will see that I have been promoting the system for over a year. Over 7000 people have viewed the site which is a lot of potential customers. So far I have not reported on the bugs.

Regards

John

Alles anzeigen

Thanks John.

1) For avoiding damage of reputation they may write and accept BETTA rules for Betta testers.
2) I also told about some bugs and obviously convenient improvements there: http://www.viessmann-modell.co…m/viewtopic.php?f=7&t=853
May be You already wrote this.
3) In addition i propose approach for light signalling. Where lights will depends as from commands as well as from block sections and turnouts positions automatically.
4) For best results J.Meier may restore BETTA versions and may propose to Viessmann head open direct communication line between users and programmers group there.
--------
Vadim.

Zitat von John Ferguson

Dear Vadim

A direct relationship between people undertaking the system development and users is essentail in my experience.
Hence if the Company adopts this approach it will improve the product in my opinion. Beta testing should be done by programmers and users.
Regards
John

Thanks, John.
But this line is too slow.
These changes can be really implemented during some days, maximum - 1 week.
And new betta version with corrected errors and improvements must be awailable at Viessmann site!
It's really! Algorythms is not so complicated.

By the way, can You see my these suggestions? :
http://www.viessmann-modell.co…m/viewtopic.php?f=7&t=853

What do You thhink about it?

Viessmann choose best strategy - using route oriented one.
But Viessman loose time, and do it extra slowly! with a lot of bugs and disconveniences!

Real disadwantages of this strategy - not a lot of bugs (This bugs can be anyway debugged by user ), but also very restricted programming!
It seems that programmers - not real railroaders. They dont feel all needs of railroaders!

For example, the main disadwantages are:
- 1) Very small quantity of commands in every field, especially in "feedback" and "on-the-way".
- 2) Abscence of AllMtxAdj options - which must automatically adjust whole safe matrix for all routes! It ll save a lot of time!
- 3) Abscence of ability to make specific routes (how to make - see my link above)
- 4) Abscence to make automatical yellow at lights and block dependant signalling(we already discussed it with J. Meier).
- 5) Abscence of making (3-minimum) different route shedules and 3 different diagramms without interlinking!!!
For example, i wish to change shedules of routes - i cannot do it! I must clear all and write all routes again! It's a lot of work!

---------
Awaiting Your respond
Vadim

Zitat von John Ferguson

HI Vadim

I think your suggestions would greatly improve the product but first I would like the current faults in the display corrected.

Regards

John

Alles anzeigen

Ok.

The screen errors are:

1) Remained (falce) occupancy (by red) when contacts are released. It seems that old occupancy cannot be resetted even after restart of commander! (i think that MEM status is mixed up elsewhere)
2) No indication of routes at new parts of screen when You move diagramm which is larger than screen.(Yellow). Refresh of this option is seems as abscent!
3) Incorrect imaging of loco names in ZNR fields. For example ICE-1 looks like as CCE.1 at the diagramm at finest scale of screen.
4) Turnout often dont indicate their real positions.
It seems that new screen elements on diagramm use parameters from old ones, and therefore indicates incorrectly.
5) Implementing Light signals with 3 or more states can lead to incorrect turnout addressing and general fault. And when switched - turnout symbol can imagine by another strange symbols(at diagramm)!
It also seems that new screen elements on diagramm dont edited correctly inside programm and use parameters from old ones, and therefore indicates incorrectly.
6) At Routes - fault in indication turnouts in switching commands option (we already discussed it)

MAIN SUGGESTION:
A) Please try to implement interlinking between elements where adjasent contacts and turnouts can be interpreted by GRAPH or CHAIN! So that, You ll give 2 best properties:
1) You can simply adjust MTXADJ automatically with any quantity of contacts per ROUTE.
2) You can simply implements block-dependant Lights signals.

B) Please try to implement programm smoothnes, where CV3 and 4 will be realised by Commander, sending multiple commands (one command per one scale of speed ) [CV3 and CV4 must be shutted off in locos]

This feature allow You to make precise braking (as in traincontroller) by using of final short braking sensors at edges of stations.
Now i use shunting (F4)+STOP commands at "on the way" page of route editor. But to use it You must doubling Your sensors at different numbers, because Commander cannot execute two commands with the same numbers of sensors! (WHY??? I SHOCKED! )

---------
Vadim