Upgrade PV600 (RS-232-DH485) comm. to ML1500 to PV+

[nicer]

Now for the hard parts.

Running the 1747-PIC/AIC+ driver on Windows computers is notably difficult. It will not run on Windows 10,8,7,or Vista at all. It will run with difficulty on Windows XP SP2 or on XP SP3 with a patch.

And you would need it to upload the PanelView Standard application file using the terminal serial port, or to upload/download/go online with the MicroLogix 1500 using Channel 1 in its current configuration.

You can use a 1747-UIC (U for USB) for both of those functions. Those work under all modern operating systems.

The better option for the PanelView Standard is to use a Flash card to copy the application off the terminal. A CompactFlash card under 2 GB, formatted for FAT16 format, in a Type II carrier is my favorite method.

The better option for the MicroLogix 1500 is to get a 1761-CBL-PM02 cable, press the DCOMM button, and connect up over the 8-pin round port using ordinary DF1 Full Duplex protocol.

Yah, I also read about this and I actually have a native SP3 but fortunately a guy named Dmroeder made patch I could also use which seem to have worked (before it's always on "Stopped" status but now it's alreaady "Running", though I haven't yet tested it actually on site):

http://www.plctalk.net/qanda/showthread.php?t=63919&page=3

So this 1747-UIC, for old PV RS-232 upload, won't need a problematic driver? How does it differ to those simple straight through cables?

Yah, there's seems a memory card slot at the back of the old PV600, but a kind of card that seems you'd can't easily find just anywhere. It was a really huge slot, I think something like around 3 inches long?

Yah I think it's best to have that 1761-CBL-PM02 cable if you want to do ML1500. But wanna ask, the comm.reset button only affects the ch.0 right, it will put the serial/RS-232 port on DF1 protocol and can be implemented even during the PLC is running w/o affecting anything (of course given there's nothing communicating on it)? I read that it can even be reverted back to whatever it was before you comm.reset by pressing it again right?

Thanks!

 

[nicer]

And last, an option:

You used DH485 over RS-232 between the PanelView and the MicroLogix on the old system because... well, I don't know why. Maybe because that PanelView was all they had handy, or because there used to be other DH485 devices on the network.

If all you have is the PanelView Plus and the MicroLogix 1500 connected with a serial cable now, there's no reason not to just use DF1 Full Duplex protocol.

It's slightly faster and there's the extra benefit that the MicroLogix serial port stays at the default DF1 Full Duplex protocol settings, which allow you to use ordinary USB/RS232 converters and the more stable and simple DF1 Full Duplex protocol in the future.

I think because the old PV600 (2711-K6C5) can only support that protocol (DH485).

Yah that's might be better but for a total newby to AB and no ML1500 cable and software like me, I guess I should stick to adapting the old communication hehe

 

[nicer]

I have another question which is about FactoryTalk View.

So the client have the FactoryTalk View V8. This seems to include the FactoryTalk View ME, the one we need to migrate the old PV600 .pba/.pva program to .mer that can be run by the new PV+.

Do you think I can be able to copy and use it just to convert/migrate the project, and nothing more, outside the plant (of course without using the included license which is reserved for their use)?

 

[nicer]

Also, I have read that generally, serial communication between DTE (PLC and PC usually) and DCE (HMI usually) device we use straight cable and between 2 DTE we use null modem.

What if we mistakenly switched the cables (or used any wrong 9pins pin config), is there a risk for burning something inside device or it would just won't communicate?

 

[nicer]

Upon re-reading everything, I came to realized that there were instances where I was confused about cables and protocols.

Generally, cable would depend on electrical system (eg, RS-232) but not on its protocol (eg, DF1, DH485). So that if I want to use the 9pins RS-232 port on left side of ML1500 LRP for laptop upload, then, irregardless of its protocol (whether it's at DF1 or DH485) I would have to use a null modem cable. If I again want to use that same port for PanelView communication, then, irregardless of its protocol again, I would have to use a straight cable.

What would be depend on the protocol is the driver I would use on the communication configuration (DF1 or 1747 PIC/AIC+ for DH485).

Right experts?

 

[nicer]

Geospark,

I also noticed you always specifically mention RSLinx Classic. Mine was just RSLinx Lite v2.41.00 which is included on PanelBuilder32 v3.81.316 installation.

Is that ok to upload the old PV600 using the straight 9pins ribbon and 1747 PIC/AIC+ driver?

 

[nicer]

Hello experts Ken and George,

I also noticed, the name of COM1 under Windows Device Manager also has changed to the name of my added 1747 PIC/AIC+ driver on RSLinx and it won't work on other software (e.g., Step 5 for Siemens S5) until I remove the driver from the RSLinx and the name would revert to normal "Communication Port".

Might this be a definitive indication that the 1747 PIC/AIC+ driver is indeed working on my patched Win XP SP3?

Thanks!

 

[Geospark]

...Ok, I'll leave it there until you have 20 more questions...

See! I knew you'd have even more questions! You certainly do need a LOT of reassuring, don't you? You are kind of asking the same questions over and over, only in a slightly different way. But I understand. You want to be double/triple sure you have everything in place before you go onsite.

Some days we are busy, so give us a chance to respond to a question (or two) before asking more. It also makes it more difficult (and timely) to compose a reply when many questions have been asked before the first couple have been answered. It can also get a bit confusing if more than one of us is trying to reply to multiple questions which may even be roughly the same. :site:

I'll answer what is directed at me, or to all. Ken can answer likewise if he sees fit. But we are here to help either way.

I see, yap I read that uploading PV600 RS-232 (DH485) directly to laptop w/9pins male serial port (using 1747 PIC/AIC+ driver on RSLinx) just need straight cable, like 2711-NC13, and which only uses ports 2,3 and 5. Since the existing 9pins female-female ribbon cable I tested is also straight, albeit uses all 9 pins, it should be ok as long as pins 2,3 and 5 are straight-connected (after all the other pins will not be used at all right?).

I'm glad you can confirm that the old straight 9pins ribbon cable is also the one to use to for new PV+!

Yes, again, it should work OK.

I see, if I want to use ML1500 LRP ch.1 (side 9pins port) I must use null-modem cable like 1747-CP3, and if ch.0, I must use the proprietary 1761-CBL-PM02. Since I don't have both, then I think, as you suggest, I better go for the ch.0 if I wanna buy (though the null modem cable might be more easily available). What do you think about the USB versions of these?

Channel 0: You need the 1761-CBL-PM02 cable to connect from your computer's DB-9 serial port to the MicroLogix 1500 Channel 0 port to go online or perform upload/download using DF1 protocol.

Channel 1: As the Channel 1 port is currently configured for DH-485, and cannot be defaulted to DF1 (DCOMM), then you would have to use a DH-485 interface converter, attached to a 1747-CP3 cable (or null modem), to communicate with your computer. You cannot simply connect between the two and use the PIC driver, without an interface converter, as you can with the PanelView for transfers.

The 1747-UIC is the modern day version of the 1747-PIC and widely used where computers do not have a native DB-9 serial port. You can use the UIC from a USB port instead of the 1747-PIC from a DB-9 serial port to communicate with controllers configured for DH-485. I would recommend you look into getting one if you are purchasing software to communicate with AB controllers configured for DH-485. It also eliminates the need to use a PIC and the troublesome driver that you are all too aware of.

---Application Conversion---

I see, I'm glad you can confirm that there's still the RS-232/Serial DH485 driver for the new PV+ (that's also for the onboard/integrated 9pins male port on the new PV+ right?)! Yap, that's what I want so that I won't need to modify anything on comm. hardware (cabling) and software (ML1500 config) for I also currently don't have ML1500 software and cable.

Yes. The Serial DH-485 driver should work for any serial port that has been configured for DH-485. You should not need to modify the comms in the MicroLogix program if sticking with the original DH-485 protocol.

So, it seems you are saying that, as part of the communication reconfiguration, I would be assigning node address for the new PV+ and the old ML1500 LRP address from RSLinx Enterprise. Will this really be "assigning" in a sense that I can change whatever node address they are already assigned (I did check the old PV600 node address from its comm.setting on its screen itself, and it's actually "2")? Or it's actually "adapting" in the sense that I need to know the node addresses and put it on the RSLinx (ie, I should check the ML1500 address and "copy" that on RSLinx) for it to work?

If the latter, then it seems I really might actually need ML1500 software and cable to check it's node address? Or the ML1500 node address can also be found on the uploaded old PV600 program on PB32 as what you seems also saying?

Good thing is that the system is just point-to-point communication between 1 PV600 and 1 ML1500 LRP.

Yes, really, you can assign any unique DH-485 node address to the Serial DH-485 driver. This, as I mentioned, is then the node address for the PanelView, as the driver performs the communications out through the serial port to the controller. If the original PanelView was using node address 2, then you just set the driver to node 2. You can find which node address the MicroLogix is using by viewing the Communications Setup in the PanelBuilder32 application.

The attached image shows how to change the driver node address in View Studio for the new PanelView comms and how the PanelBuilder32 Communications Setup window looks to retrieve the MicroLogix node address.

Note: Besides using PanelBuilder32 to find the controller node address, you do not need programming software for the MicroLogix just to find this out. If you do get set up with comms from the MicroLogix to your computer, over DH-485, then you can use RSLinx Classic Lite to view the MicroLogix 1500 node address by browsing to it through the DH-485 driver. RSLinx Classic Lite will just display the controller and its node address, which is all you would need.

Next...

 

[Geospark]

See, here are five more consecutive posts in a row with many more questions without giving time to answer the others. Slow down, a little, please.

I have another question which is about FactoryTalk View.

So the client have the FactoryTalk View V8. This seems to include the FactoryTalk View ME, the one we need to migrate the old PV600 .pba/.pva program to .mer that can be run by the new PV+.

Do you think I can be able to copy and use it just to convert/migrate the project, and nothing more, outside the plant (of course without using the included license which is reserved for their use)?

An unlicensed copy of FactoryTalk View Studio can only open applications with 5 or less displays. If your clients application has more than 5 displays, then you will need a licensed (activated) copy to work with it.

Also, I have read that generally, serial communication between DTE (PLC and PC usually) and DCE (HMI usually) device we use straight cable and between 2 DTE we use null modem.

What if we mistakenly switched the cables (or used any wrong 9pins pin config), is there a risk for burning something inside device or it would just won't communicate?

In general, you should have nothing to fear except the comms will not work. But there are exceptions with some connection cables. For example, native DH-485 ports, such as on the 1747-UIC, SLC 5/03, some PanelView models, et al, utilize RJ-45 standard sockets. These can be mistaken for Ethernet ports, which also use the RJ-45 standard. If you mistakenly connect an Ethernet crossover cable between some of these devices and others, instead of the correct serial cable, you can cause irreparable damage. Another example is the 8-pin mini-Din round port on the MicroLogix 1200/1500. These ports can provide power on certain pins and if carelessly connected with a user made cable or even a breakout cable, such as the 1763-NC01, they can do harm.

These are exceptional cases, but worth noting. Again, in general, you should be OK.

Upon re-reading everything, I came to realized that there were instances where I was confused about cables and protocols.

Generally, cable would depend on electrical system (eg, RS-232) but not on its protocol (eg, DF1, DH485). So that if I want to use the 9pins RS-232 port on left side of ML1500 LRP for laptop upload, then, irregardless of its protocol (whether it's at DF1 or DH485) I would have to use a null modem cable. If I again want to use that same port for PanelView communication, then, irregardless of its protocol again, I would have to use a straight cable.

What would be depend on the protocol is the driver I would use on the communication configuration (DF1 or 1747 PIC/AIC+ for DH485).

Right experts?

Just to note - If you were using the side port with DF1 you would just need the 1747-CP3, or a null modem cable. If using it with DH-485 you would also require an interface converter, such as the 1761-NET-AIC+, 1747-UIC or older 1747-PIC. RSLinx Classic cannot communicate directly with controllers using the DH-485 protocol.

The device you connect to a port can vary the cabling option required. A port is not tied to one specific type of cabling or cable. But in some cases that selection can be dependant on which protocol is to be used, although it is usually either RS-232 or RS-485 wiring. DF1 uses RS-232, DH-485, Modbus, etc., use RS-485. For instance, the Channel 0 8-pin mini-Din port on the MicroLogix 1500 can be configured for several different protocol options. So both the chosen protocol and the connected device can have a bearing on which cabling is required. You can also, for instance, attach a null modem adapter to the DB-9 end of a 1761-CBL-PM02 cable in order to test certain comms between devices.

An example...

FactoryTalk View Studio allows you to setup temporary comms from your computer to a controller so as to carry out a "Test Application". FTVS runs the application on your computer instead of on the PanelView terminal. So FTVS simulates the terminal while communicating with the controller. This allows you to test your application before downloading it to the actual terminal. You set this up under the Design (Local) tab. If you were using Channel 0 on the MicroLogix 1500 to communicate with the terminal proper, but wanted to test first, you would attach the null modem adapter to the 1761-CBL-PM02 cable and connect it to your computer instead. When connecting to the terminal you would remove the adapter.

Geospark,

I also noticed you always specifically mention RSLinx Classic. Mine was just RSLinx Lite v2.41.00 which is included on PanelBuilder32 v3.81.316 installation.

Is that ok to upload the old PV600 using the straight 9pins ribbon and 1747 PIC/AIC+ driver?

RSLinx Classic is the software. RSLinx Classic Lite is the free, unlicensed edition. There is or has been at one point or another different editions available - RSLinx Classic OEM, Professional, Gateway, Lite, but they all install the same software. The type of licence one might purchase unlocks whichever edition features that licence permits.

The RSLinx Classic Lite edition should work fine, although v2.41 is a little older now.

Hello experts Ken and George,

I also noticed, the name of COM1 under Windows Device Manager also has changed to the name of my added 1747 PIC/AIC+ driver on RSLinx and it won't work on other software (e.g., Step 5 for Siemens S5) until I remove the driver from the RSLinx and the name would revert to normal "Communication Port".

Might this be a definitive indication that the 1747 PIC/AIC+ driver is indeed working on my patched Win XP SP3?

Thanks!

Yes, definitively, that would be the normal behaviour. It appears to be working as expected and "should" work for you on site.

Tip of the day...

Now, try not to repeat what has been written in a twisted form of the same questions. Try instead to digest the information and if you are happy with its contents and validity, then say so, or leave it at that. If NEW questions should arise from the above, then fire away and try to keep them concise and to the point, but not to any of the points already raised and answered.

Regards,
George

 

[nicer]

See! I knew you'd have even more questions! You certainly do need a LOT of reassuring, don't you? You are kind of asking the same questions over and over, only in a slightly different way. But I understand. You want to be double/triple sure you have everything in place before you go onsite.

Some days we are busy, so give us a chance to respond to a question (or two) before asking more. It also makes it more difficult (and timely) to compose a reply when many questions have been asked before the first couple have been answered. It can also get a bit confusing if more than one of us is trying to reply to multiple questions which may even be roughly the same. :site:

I'll answer what is directed at me, or to all. Ken can answer likewise if he sees fit. But we are here to help either way.



Next...

First of all, I'm very thankful for your patience and understanding sir Georgre for someone like be that even I myself can see how my inquiries can really be annoying. Aside from me being totally new to AB, I'm also on what you can say a bad situation that I really need to confirm everything.

I also admire how you can point bad habits on a nice way so that I could change it instead of being annoyed and just ignore me. I really appreciate it. Now..

So it seems I couldn't actually communicate laptop to ML1500 LRP's 9pin port, configured as DH485, by simply using null modem like 1747-CP3 (which both of you and sir Ken seem to say on your previous post). Instead I would need some media and/or protocol converter like 1747 UIC.

If this is the case, then I guess the 1761-CBL-PM02 is really the most convenient way to communicate laptop w/ ML1500 for ch.0 is also usually reserved for this purpose (of course assuming the laptop has 9pins COM port).

---PV+ on ML1500 Ch.0---

Now I have a question, what if I, for some reason, want the new PV+ to communicate on ch.0, I couldn't use this same 1761-CBL-PM02 right since it would now be between DTE and DCE (hence would require some straight-through pin config)?

Could I use something like 2711-NC21 for this purpose? If so, would I be restricted on just sone protocol?

---Other old PV RS-232 (DH485) Upload Method---

Also, sir Ken have said that I can also use 1747 UIC (with RS-232 for the device side) for uploading old PV600 and I've read the manual that I would use DF1 driver for this (so now I understand how the problematic driver is eliminated).

My question is, is there any more alternative aside from this to upload the old PV600 RS-232 (DH485)?

1 other way probably is by the huge memory cards slot behind the old PV, can you give me some details on how and what do I need for that?

Thanks!

 

[nicer]

Geospark,

Thank you very much also for your insightful and very detailed answer to all the rest of my questions (on setting up the new PV+ comm., on software copy, on effects of wrong pin config., on how media and protocol both affects cabling, etc.), indeed you left nothing unanswered! You really seem also enjoying answering questions and thus helping us newbies!

I (and I'm sure also those other readers that would benefit on this) couldn't thank you enough for this! Keep up the good work sir George [salute]!

 

[Geospark]

First of all, I'm very thankful for your patience and understanding sir Georgre for someone like be that even I myself can see how my inquiries can really be annoying. Aside from me being totally new to AB, I'm also on what you can say a bad situation that I really need to confirm everything.

I also admire how you can point bad habits on a nice way so that I could change it instead of being annoyed and just ignore me. I really appreciate it.

You are most welcome and I am glad you took it as intended, as constructive criticism and I do not find your posts annoying.

...So it seems I couldn't actually communicate laptop to ML1500 LRP's 9pin port, configured as DH485, by simply using null modem like 1747-CP3 (which both of you and sir Ken seem to say on your previous post). Instead I would need some media and/or protocol converter like 1747 UIC...

Channel 1: As the Channel 1 port is currently configured for DH-485, and cannot be defaulted to DF1 (DCOMM), then you would have to use a DH-485 interface converter, attached to a 1747-CP3 cable (or null modem), to communicate with your computer. You cannot simply connect between the two and use the PIC driver, without an interface converter, as you can with the PanelView for transfers.

Yes, if not clear earlier, then I apologize. As I stated above, you would use the 1747-CP3 only from the DB-9 side port if using DF1. If the port is set to DH-485, you would have to use a 1747-CP3 with a 1747-UIC (USB Interface Converter) or the older 1747-PIC (Personal Computer Interface Converter), or indeed you can use a 1761-NET-AIC+ and just the PIC driver.

...If this is the case, then I guess the 1761-CBL-PM02 is really the most convenient way to communicate laptop w/ ML1500 for ch.0 is also usually reserved for this purpose (of course assuming the laptop has 9pins COM port)...

It is if you do not have an interface converter to communicate with the Channel 1 port that is set for DH-485, and the Channel 0 port is free and either set to DF1 or defaulted to DF1 (DCOMM).

...---PV+ on ML1500 Ch.0---

Now I have a question, what if I, for some reason, want the new PV+ to communicate on ch.0, I couldn't use this same 1761-CBL-PM02 right since it would now be between DTE and DCE (hence would require some straight-through pin config)?

Could I use something like 2711-NC21 for this purpose? If so, would I be restricted on just sone protocol?...

Yes. The default cable for connecting a MicroLogix Channel 0 8-pin mini-Din port to a PanelView Plus DB-9 serial port is the 2711-NC21 (5mtrs) or the 2711-NC22 (10mtrs), and yes, these are straight through cables. You can, alternatively, use the 1761-CBL-PM02 with a null modem adapter, which adapts the cable to a straight through configuration.

---Other old PV RS-232 (DH485) Upload Method---

...Also, sir Ken have said that I can also use 1747 UIC (with RS-232 for the device side) for uploading old PV600 and I've read the manual that I would use DF1 driver for this (so now I understand how the problematic driver is eliminated).

My question is, is there any more alternative aside from this to upload the old PV600 RS-232 (DH485)?

1 other way probably is by the huge memory cards slot behind the old PV, can you give me some details on how and what do I need for that?...

Yes. The 1747-UIC would eliminate the need to have the PIC driver working at all and I have already advised you to get one, if you are going to be working a good bit with DH-485 Allen Bradley equipment.

If not, or you do have the PIC driver working (it appears to be ready to use), then you can still attempt to transfer the application by just using the 2711-NC13 or equivalent straight through cable (2-2, 3-3, 5-5) and the 1747-PIC / AIC+ driver. You do not need the actual 1747-PIC to make this connection.

As for the memory card option: The PCMCIA slot supports Flash memory cards...

The older Linear Flash memory cards are supported up to firmware revision 4.30...

2711-NM11
2711-NM12
2711-NM13
2711-NM14
2711-NM15

The "newer" Flash ATA memory cards are supported from firmware revision 3.0 or higher...

2711-NM24
2711-NM28
2711-NM216
2711-NM232

Only PanelView terminals using firmware revision 3.0 - 4.30 support both card types. Depending on your terminal's firmware revision, you may have to choose one or the other specifically. These cards are obsolete, but they can still be purchased in certain quarters.

Personally, and even though I usually advocate the use of memory cards (CF, USB Flash) for terminal transfers instead of cabled options, I would not go down the memory card route for the PanelView Standard if you don't already have one.

Thank you very much...Keep up the good work sir George [salute]!

Thank you for your kind words, and yes, I do enjoy "teaching" if it could be called that.

And please do continue to call me "sir George"! I rather like it.

Regards,
George

 

[nicer]

Hello experts!

I've successfully uploaded the old PV600 RS-232 (DH485) application using the existing straight-through 9pins ribbon cable + 1747 PIC/AIC+ driver on RSLinx on my laptop w/ native 9pins! Thanks to all of your help sir Mickey, Ken and George!

I also got no problem loading and running the application to the new PV+ (though I had to "downgrade" the application file made from FTV ME v8 to v7 since the new PV+ only have v7 firmware.

But unfortunately I wasn't able to test the runtime application so I need your advise again to anticipate potential problem. I have some concerns on the conversion procedure using FactoryTalk View Machine Edition V8, particularly, as always, on the communication:

1) The shortcut name on FactoryTalk View ME would be the node name on PanelBuilder32 right?

2) On the shortcut verification (after following sir George's instructions on setting the new PV+ communication) there's some suspicious warnings (please see attached file).

3) During Application Test or Create Runtime Application there would be a lot of error on which is mostly "failed to add item.." (please see attached file)

I also have attached the conversion log file of the which is more of the "multistate" which seem to be just fine (as the migration manual said, mostly just the binary status).

Thanks much for any response!

 

[Geospark]

1) The shortcut name on FactoryTalk View ME would be the node name on PanelBuilder32 right?

Yes. The node name should be the shortcut name.
The node number was 1 for "MICRO1500" in PB32, yes?

2) On the shortcut verification (after following sir George's instructions on setting the new PV+ communication) there's some suspicious warnings (please see attached file).

Have you attempted to connect the controller to your computer to perform a Test Application? If not then the Design (Local) path is of no use. But either way you have unfortunately hit a slight snag on the Design (Local) shortcut. You cannot use the Serial DH-485 driver for local communications. It only supports remote communications i.e. Runtime (Target). So it cannot be used to create a path from FTVS to the controller to perform a Test Application. Instead, you can use that much talked about Channel 0 and DF1 to make a test path from your computer to the controller. This is a temporary path just for testing and just applied to the Design (Local) shortcut path. You would leave the Runtime (Target) path as is.

Do you have a 1761-CBL-PM02 cable? I mentioned this earlier, but I'll repeat it here. You would normally connect only this cable from the Channel 0 port to your computer's DB-9 serial port while programming the MicroLogix. But to allow your computer act as a PanelView terminal for testing, you must make a straight through connection, similar to the real terminals connection. To do this you can attach a null modem adapter or even cable between the 1761-CBL-PM02 cable and the computer. Then add a DF1 driver under Design (Local) and link a similar shortcut to it. The DF1 driver will communicate the same PLC addresses as the DH-485 driver eventually will.

3) During Application Test or Create Runtime Application there would be a lot of error on which is mostly "failed to add item.." (please see attached file)

Again, without a valid Design (Local) path assigned, you will not establish good communications to the controller during Test Application and will see many possible failed read and writes. If Create Runtime Application (where you compile the MER file for the terminal) is throwing errors then there are possible discrepencies still in the application after the conversion. These can be very specific and would need closer inspection.

I would advise you to set up that Design (Local) path for testing, especially after a conversion. It can be painful making many small edits and always having to compile the MER Runtime file and load and run it on the actual terminal. Test Application let's you quickly check your modifications without all that hassle. Only compile and go to terminal when you're sure you have something solid to test proper.

Regards,
George

 

[nicer]

Sir George,

1) Yap, it's MICRO1500

I see, so this warnings and errors are because Test Application is simulating the runtime from PC and:

2) the simulation PC isn't possible to communicate via Serial DH485 hence the "driver cannot be used" (even though it's inside "Runtime" tab not "Local") and;

3) it isn't seeing these tags (since it's not connected to the ML1500) hence the "failed to add item".

So then it seems these aren't necessarily problems, glad to know!

Yap that's a good way to test (if I can get the cable) and thanks for being advance again, anticipating I'd probably use, and have problem with, the null modem on Test Application!

BTW, at least, I can already see my added Serial DH485 driver on PV+ local communication settings!hehe

Also about the duplicate post, copy sir! Sorry about that (I'm thinking maybe the guys that have already read this thread might also have been annoyed so it'd probably better to create another one more clean hehe). I'll delete it right away.

Thanks again for very informative response!