Импорт данных из бинарного файла (.bin) на лист Excel

[Wer666]

EducatedFool, спасибо огромное за ответ!
А можно по подробнее? Как воспользоваться вашим макросом?
Не ругайте сильно - я не сильно разбираюсь в программировании.

[AndVGri]

Прочитать можно с конвертированием в Double, для примера - чтение числа из Long64

Public Sub readLong64()
    Dim b8(0 To 7) As Byte
    Dim fNum As Integer
    Dim i As Long
    Dim vResult As Double, vPower As Double
    
    fNum = FreeFile
    Open "c:\temp\1.1" For Binary Access Read As #fNum Len = 8
    vResult = 0#: vPower = 1#
    Get #fNum, , b8
    For i = 0 To 7
        vResult = vResult + vPower * CDbl(b8(i))
        vPower = vPower * 256#
    Next i

    Debug.Print vResult
    Close #fNum
End Sub

А для работы лучше объявить структуру

Type binData
    vDate(0 To 7) As Byte
    Volume1 As Double
    Volume2 As Double
    Price1 As Double
    Price2 As Double
End Type

И читать переменной такой структуры, задав Len=40

[Wer666]

Попробовал выполнить вышеуказанный макрос, но результатов не получил(((
Что мог сделать не так?(

[AndVGri]

Wer66 процедура readLong64 считывает из файла 1.1 в папке c:\temp первых 8 байт и преобразовывает их в число типа Double. Вы можете поменять путь и имя к вашему bin файлу, чтобы проверить корректность вычисления такого преобразования. Я привёл лишь пример. Что конкретно у вас «никаких результатов» дало? Что-то же Debug.Print должен же был выдать в панели Immediate или, хотя бы, должно было появиться сообщение об ошибке.

[DiemonStar]

Уважаемый AndVGri,

а Вас не смущает, что при преобразовании целого в дробное теряется некоторая часть точности. Например, для приведенного здесь примера, число:
3806576592579264512 (34 D3 AD 3E 2B 01 00 00h), значение после преобразования станет: 3806576592579260000

Согласитесь, терять изрядную долю числа не самый правильный подход.

С учётом того, что стандартными функциями преобразование сделать практически нереально, то есть два пути: либо, как предложено выше, провести преобразование исходного файла в воспринимаемый программой формат отдельной консольной утилиткой, которую вполне реально запустить прямиком из макроса, либо самому написать функционал по работе с длинными числами.

з.ы. при правильном подходе можно заменить Long64 строкой, но неясно как планируется его дальше обрабатывать...

[AndVGri]

Все в наших руках. можно сделать и преобразование в текс т- завтра подумаю. Но у автора 13 знаков всего в примере, не подскажете алгоритм записи даты и времени в целое 64 число?

[DiemonStar]

не подскажете алгоритм записи даты и времени в целое 64 число?

А зачем? Double сам по себе 64-х разрядное число с плавающей точкой, т.е. в условия вписывается вполне. В Excel нет поддержки только целочисленных значений такой длины.

Но у автора 13 знаков всего в примере

Смотря в каком порядке считывать байты - в прямом или обратном. Да и в любом случае, со временем количество цифр может достигнуть критического уровня.

[AndVGri]

Хм, уважаемый DiemonStar, порядок байтов для Long64, предполагаю, стандартный – слева младший байт, справа старший. По поводу перспективы, я не зря спросил про алгоритм вычисления даты, представленной *типом Long64. Предположим, он предполагает за 1 принимать одну сотую секунды от начала нашей эры, тогда имеем для 2100 года 2100*366*24*3600*100=6 640 704 000 000 – как раз 13 знаков. Думаю, вы согласитесь, что до 2100 года макрос вряд ли будет использоваться. Потеря точности идёт с 256^6, 256^7, можно их, используя VS получить в текстовом виде и умножать и складывать поразрядно с значениями 6 и 7 байтов, работая с текстом (неспешно будет, но результат…). Далее, разбиваем полученный результат на части, так чтобы сумма младшей части с остальным значением (с 0 по 5 байт) не имела переноса разряда. Младшую часть складываем со значением с 0 по 5 байт и как текст добавляем к старшей текстовой части. Если бы был алгоритм представления даты в целочисленном виде, то можно было бы и конвертер написать. Только будет ли этим заниматься ТС? Алгоритм то набросать можно, но судя по вопросам ТС – возьмётся ли он его реализовывать?

[doober]

Даты в файле нет.исходные данные по дате в файле INI.
1 байт =номер устройства,3 байта =показания прибора
Но у меня количество данных в 3 раза меньше чем в окне программы.
Надо алгоритм программы знать
привожу выдержки
Получил для 2х устройств

2 -2,9521
3 0,0052
2 -2,9501
3 0,0057
2 -2,9501
3 0,0046
2 -2,8463
3 0,0046
2 -2,8874
3 0,0046
2 -2,9521
3 0,0077
2 -2,9943
3 0,0057

Для 8 устройств.

0 0,0011
3 -0,0253
6 -0,0052
1 -0,0271
4 -0,0155
7 0,0099
2 -0,0059
5 0,248
0 0,0004
3 -0,0275
6 -0,0059
1 -0,0256
4 -0,0155
7 0,0092
2 -0,0059
5 0,2484
0 0,0015
3 -0,0238
6 -0,0059
1 -0,0263
4 -0,0155
7 0,0095
2 -0,0051
5 0,3431

[DiemonStar]

По поводу перспективы, я не зря спросил про алгоритм вычисления даты, представленной *типом Long64.

Дата практически во всех языках программирования представлена числами с плавающей точкой (но никак не целочисленными), где целая часть числа = количеству дней, а дробная = части суток на текущий момент. И такое число очень даже просто преобразовывается в дату.
в условии написано:

Время - 64-bit Long

т.е. либо автор ошибается с форматом записи, либо используется нестандартный способ хранения, а это само по себе вызывает некоторые проблемы, основная из которых - отсутствие информации.

порядок байтов для Long64, предполагаю, стандартный – слева младший байт, справа старший.

ну так именно в этом порядке я и сделал преобразование, а не как это сделал автор: http://programmersforum.ru/showpost....06&postcount=2