The vcdMaker is an open and free application for translating text log files into the VCD (Variable Change Dump) format files. It is supposed to help engineers to debug their applications and systems.
There are many free and commercial tools available on the market which display VCD format files as a waveform. One of the free tools has been described in the manual as well.
We appreciate your feedback. Share your ideas, success stories and comments via e-mail.
The vcdMaker documentation can be downloaded from here!. It is also provided in the installation package.
Installer - The latest Windows 32-bit installation package. It updates the user’s path so as the application could be invoked from anywhere. The application can be fully removed during the uninstallation process.
ZipArchive - The archived version of the application for those who do not like installation packages.
vcdMaker-2.0.1-amd64.rpm - The RPM package.
vcdMaker-2.0.1-amd64.deb - The DEB package.
vcdMaker-2.0.1-amd64.zip - The zipped archive of binaries.
The introduction to the idea has been put together in the form of a short video which can be watched below.
As the experience shows, no matter what the industry is and what the target application is, people tend to create log files to analyze their systems and applications. In many cases these are many megabytes files. People just read them or prepare scripts to get them analyzed automatically. The idea presented here compromises these two approaches by visualizing the log. Although the analysis is still manual the engineer is given a kind of freedom and flexibility in the system’s exploration. One can easily measure time events or change the format of the displayed data.
Of course logs are not usually created in the format used by vcdMaker. Provided, they contain time stamps, variables’ names and their values they can be easily transformed to the vcdMaker format. Short Perl, Python or awk script shall suffice and most programmers will handle it easily.
It is beneficial to have the insight into the system at the every stage of its development, not only while hunting for bugs. Quite often people rely on assumptions. We all have heard statements like these: ‘This library will never return values out of range.’ or ‘I would be surprised to see this interrupt happening often.’. Guess what? It turns out that it is not so uncommon to see the library returning unexpected values and the interrupt handler is invoked every 350 us. Having means to see those things in advance might improve one’s design yet before the bugs sneak out.