WinPCD on windows 10 ...... can't make it work

Status
Not open for further replies.
For me the WinPCD_1_5_0_1 installer does not work, but running the exe itself from the \WinPCD_v1.501\Application Files\WinPCD_1_5_0_1\ works ok on Win10 1607 and shows the sample files from the Application folder.

You might want to try to right click on the WinPCD.exe and choosing the
Compatibility tab -> and enable the 'run in compatibility mode' -> Windows 7. That might help.
 
No, I was almost thinking og adopting another program .... but if you can help it would be great 🙂
Baldin
One problem I have seen is measurement files (FRD, ZMA) with a comma as the separator for decimals whereas WinPCD requires a period. WinPCD accepts separation between the three data columns as one or more spaces, a tab or a comma (i.e. a CSV file). The latter means that the data files cannot use a comma as a separator.

dlr
 
Hi ergo and dlr (Dave I guess)
Running the program directly from \WinPCD_v1.501\Application Files\WinPCD_1_5_0_1\ and setting the country and format to USA makes it work. The last part (having to change windows settings to USA) is a bit of a hassle. .... would be a nice improvement to make this work for all country settings 😉
But at least now it can work :up:

My files uses spaces as separation:
* Freq(Hz) SPL(dB) Phase(degrees)
201.587 40.958 171.980
204.520 40.376 166.747
207.494 39.316 159.781
210.512 37.908 154.518
213.574 36.406 153.461
216.681 35.187 157.448
219.833 34.644 165.194

For the country settings I think the problem lies in that we in DK uses a comma in stead of a point to describe the decimals (yes this probably sounds strange 🙂 ) ...... I guess you are using some standard function to read from the files which doesn't take this into account and makes an interpretation of the number based on the location and language setting ... and therefore thinks these are wrong numbers as the decimals are separated with a point in stead of a comma .....
But of course I'm guessing here.

Thanks and kind regards Baldin 🙂
 
I'm glad to know that you got it to work. The file that you show is what is expected. I think that you are correct that the problem does lie in the program in that when the file is read, the text has to be converted to double (real) values. Evidently the built-in function (method) expects to see text in the form use by the country selected as you indicated. That means the text may need to have a comma in your case or the read routine would have to know how to recognize and handle periods when commas are expected. As it is the program only expects periods as decimal separators.

I don't know exactly what it would take to make it accept period or comma for the data in all cases. One problem is those measurement systems that output comma separated values rather than space or tab. Add to that the case when outputting a value of 90 db for example, I know of one that will output "90." rather than "90.0" that makes parsing it more difficult if it were "90,". I once had to develop a routine to parse a very long text string that had a wide range of possible values all concatenated, both text and numbers. It had to handle so many that it took two weeks of work to guarantee error-free operation. It was the most frustrating work I've ever had to do.

Dave
 
Status
Not open for further replies.