[TOOL] What version is this MER/APA anyway?

Ok I changed access settings

Ver 6.1
https://drive.google.com/file/d/1dZVwXXG2CupFGbDpyfeR9KPJV9UdWJUe/view?usp=sharing

Ver 12
https://drive.google.com/file/d/1EWa-C8zvKlG0NoZCM4fVLMCF2VSfT9nF/view?usp=sharing

I'll get the backups. I suspect you will need FT View SE to restore them. Whereas these files you can open with Notepad++ or whatever your preferred tools are

OG

Cool thanks. I actually setup SE on my home machine in a VM last nigh, just in case. We have a toolkit that includes SE, our division just doesn't use it.
 
Are they both 32 bit or is the later one 64 bit?

The 6.1 was on an XP machine so it would be 32-bit. The 12.0 was Windows 10 64-bit so is likely 64-bit. I think somewhere around v10 or v11 they made it so FTV could work with both without the whole export thing being needed.

OG
 
Jeez, I don't know how many of you guys have experience the new guy at the office, who shows up like a wrecking ball and does violence to all the norms in an effort to prove themselves.

Well, I think something like that has been going on with Rockwell regarding all of these files. While they all use the same file format, it's like a different person got a crack and choosing how they are organized. The apb is obscene.

All critical files (MER, APA, APB, SED, MED) are ole file structure. All of them can be unzipped with a zip tool like 7zip except the SED. All of them can be read using python's olefile module, except the APB. When you unzip the APB, the contents look nothing like APA/MER, there are additional ole files that end in .bk and .bak. The project structure is compressed in a horribly named .bk file, while the project information is compressed in a .bk file named after the application. Compare that to MER/APA, where when you decompress the MER/APA, all the details are right there in front of you. EDIT: Turns out the APB is a 7z file, the bk/bak file details still hold true.

I rewrote the tool in python, which I was able to move away from unzipping. This was nice because it's fast and less messy. Now, I'm finding myself adding all of these stupid cases of "If this file" or "If that file", where I'll have to unzip in some cases. What a stupid mess for no reason.

A service guy at work, years ago, made fun of me for using 7zip over WinRAR. So, when he asked me to send him a file, I zipped it, then tarballed it (tar.gz), 7zipped it, renamed the extension to txt and made a self extracting zip file with a README, telling him to change the extension back to 7z. Then finally made a multi-part RAR, each of the 6 parts were on a different thumb drive, then I mailed them to him. The file wasn't actually what he wanted, it was a README that just said "7zip FTW lol". When he called me, ****ed, I emailed him the file he needed. I feel like he went to work at RA, convinced them that they need a new APB file type, and payed me back. You win Darryl.
 
Last edited:
Jeez, I don't know how many of you guys have experience the new guy at the office, who shows up like a wrecking ball and does violence to all the norms in an effort to prove themselves.

Well, I think something like that has been going on with Rockwell regarding all of these files. While they all use the same file format, it's like a different person got a crack and choosing how they are organized. The apb is obscene.

All critical files (MER, APA, APB, SED, MED) are ole file structure. All of them can be unzipped with a zip tool like 7zip except the SED. All of them can be read using python's olefile module, except the APB. When you unzip the APB, the contents look nothing like APA/MER, there are additional ole files that end in .bk and .bak. The project structure is compressed in a horribly named .bk file, while the project information is compressed in a .bk file named after the application. Compare that to MER/APA, where when you decompress the MER/APA, all the details are right there in front of you. EDIT: Turns out the APB is a 7z file, the bk/bak file details still hold true.

I rewrote the tool in python, which I was able to move away from unzipping. This was nice because it's fast and less messy. Now, I'm finding myself adding all of these stupid cases of "If this file" or "If that file", where I'll have to unzip in some cases. What a stupid mess for no reason.

A service guy at work, years ago, made fun of me for using 7zip over WinRAR. So, when he asked me to send him a file, I zipped it, then tarballed it (tar.gz), 7zipped it, renamed the extension to txt and made a self extracting zip file with a README, telling him to change the extension back to 7z. Then finally made a multi-part RAR, each of the 6 parts were on a different thumb drive, then I mailed them to him. The file wasn't actually what he wanted, it was a README that just said "7zip FTW lol". When he called me, ****ed, I emailed him the file he needed. I feel like he went to work at RA, convinced them that they need a new APB file type, and payed me back. You win Darryl.

Is there a tool to read .acd as well?
 
Is there a tool to read .acd as well?

No, they use what seems to be their own proprietary format for ACD. If you start a new blank project, save it. Then add one tag and save it. now open them in a hex editor and compare, you'll fined they are almost 100% different.
 
Is there a tool to read .acd as well?

Do you just want to know what version it was saved in? Easiest way is to open it in a text editor and it will tell you the version, along with each save made since the file was generated.
 
Do you just want to know what version it was saved in? Easiest way is to open it in a text editor and it will tell you the version, along with each save made since the file was generated.

This is true for ACD files, the tool that is the subject of this thread reads the version from the plain text header.
 
I use it occasionally for not just MER/APA's but ACD's as well. If you're ever curious, you can open the ACD as a text file and see all the times that it was saved and what version it was, so you can see the whole version history of a file. Of course after that information becomes gibberish.
 
So I added the ability to unpack and get to the VERSION_INFORMATION file that is packed into the APB in a way unique to that file. After finally getting it debugged, the first success reports v1.0. WAT? So I open the file and look at its contents, sure enough, it says 1.0 in it. I just don't get it. The MER and APA have a VERSION_INFORMATION file that has the version encoded in it. Fast forward to the APB, the file exists, but doesn't contain the actual version it was generate with. Sad face emoji.
 
Jeez, I don't know how many of you guys have experience the new guy at the office, who shows up like a wrecking ball and does violence to all the norms in an effort to prove themselves.

Well, I think something like that has been going on with Rockwell regarding all of these files. While they all use the same file format, it's like a different person got a crack and choosing how they are organized. The apb is obscene.

All critical files (MER, APA, APB, SED, MED) are ole file structure. All of them can be unzipped with a zip tool like 7zip except the SED. All of them can be read using python's olefile module, except the APB. When you unzip the APB, the contents look nothing like APA/MER, there are additional ole files that end in .bk and .bak. The project structure is compressed in a horribly named .bk file, while the project information is compressed in a .bk file named after the application. Compare that to MER/APA, where when you decompress the MER/APA, all the details are right there in front of you. EDIT: Turns out the APB is a 7z file, the bk/bak file details still hold true.

I rewrote the tool in python, which I was able to move away from unzipping. This was nice because it's fast and less messy. Now, I'm finding myself adding all of these stupid cases of "If this file" or "If that file", where I'll have to unzip in some cases. What a stupid mess for no reason.

A service guy at work, years ago, made fun of me for using 7zip over WinRAR. So, when he asked me to send him a file, I zipped it, then tarballed it (tar.gz), 7zipped it, renamed the extension to txt and made a self extracting zip file with a README, telling him to change the extension back to 7z. Then finally made a multi-part RAR, each of the 6 parts were on a different thumb drive, then I mailed them to him. The file wasn't actually what he wanted, it was a README that just said "7zip FTW lol". When he called me, ****ed, I emailed him the file he needed. I feel like he went to work at RA, convinced them that they need a new APB file type, and payed me back. You win Darryl.

Jeez, remind me never to **** you off Dmoeder 🤣
 
With ME, you get a notification that an older project will be converted to your current version at the point you open the project for the first time, after it was restored. To me, that means somewhere in the project directory, there is record of this. The file VERSION_INFORMATION is this file in ME land. Turns out, that is not the only place the information exists. The MED file also contains it, in a different file within the MED. Does SE behave this way? When you restore an older project, the first time you open it, it alerts you that the version is older?

What would be helpful is a SED, or a full project directory of the exact same application but in two different versions. I was able to do this easily in ME because I could just make MER's in any version I want. I suppose this is more difficult in SE because they are not compiled. I guess one way to get this would be to restore a project that is v8, for example. Zip that up. Then open the project and let it be converted to the new version, zip that up. Then I can poke around at the differences. If someone had the time to get me those details, that would be super helpful.

I've unzipped the .apa file, and I see the "PRODUCT_VERSION_INFORMATION", "TargetPlatform", and "VERSION_INFORMATION" files. They're all 1 KB and not readable when I open with notepad++. How can I read these files?
 

Similar Topics

With Studio5000 Version 31, whenever I try to enable the bookmark (Menu/VIEW/Toolbars/Bookmark Toolbar) by checking the box, it crashes with a...
Replies
12
Views
8,393
I am trying to convert a program from MLX to CpLX using the conversion tool. I am getting an error unable to find *.txt file. Would anyone be able...
Replies
3
Views
1,700
Hi, I have a new PanelView Plus 1000 that I am using to replace an old Panelview Plus (pre v6, I'm not sure exactly what version). I have a clone...
Replies
4
Views
2,784
I'm trying to use the FactoryTalk Legacy Tag Conversion Tool out on a customer site. I loaded the tool on one of the customer's Windows XP...
Replies
8
Views
4,502
Good day can anyone tell me the name of the program to convert a ab 2711 panelview program from a older firmware to a newer firmware, like a...
Replies
5
Views
3,120
Back
Top Bottom