LabVIEW 64bit OPC client

[Jonvo]

Thanks Thierry for the confirmation.

Thanks Rolf for pointing out why....

[PiF]

Dear Forum

I'm currently facing this same problem...

I work on a large project with vision components a variable engine and a communication to a Schneider OPC (using datasockets).

The system worked fine in LV 8.6 (and windows vista)

I'm in the process of transferring the station to a windows 7 LV2014 64bit system.

I don't manage to connect to the OPC using datasocket.

The reason to use LV 64bit is to improve the vision performances.

Is the simplest solution to run my main program in 64bit and have a vi running in 32bit to manage the communication part through local variable?

or is there an easy way to "encapsulate" 32bit datasockest vi in LV 64bit?

Thank you for your advice!

best regards

PF 

[Jonvo]

Hi PiF,

Yes, the simplest solution is to run my main program in 64bit and have a vi running in 32bit to manage the OPC communication part.

That is the way I solved this.

There is no way to  "encapsulate" 32bit datasockest vi in LV 64bit.

Kind regards,

Jonas

[rolfk]

---

@Jonvo wrote:

Hi PiF,

There is no way to  "encapsulate" 32bit datasockest vi in LV 64bit.

Kind regards,

Jonas

---

Nope! Or at least not without something called thunking that you have to write in AMD64 assembly code. Which makes this an exercise in vain that should be avoided at all costs.

[natasftw]

The thread had already determined you'd need to interface between 64-bit and 32-bit if you wanted to use OPC.

But, I'm a bit curious about your application.  If it was working fine on a system using Vista and 8.6, I'd imagine you had a rather old system.  If that system worked just fine, are you changing your data set?  If you're not changing the type of data you're reading, I'd expect you could maintain the 32-bit system without any issues.  A better computer shouldn't process your data slower.  In this case, the "simplest" solution is not expanding it to 64-bit and splitting your project.

[PiF]

Thank you Jonas, Rolf and Natasftw for your answers.

I have tested my programm in 32 bit and everything is working fine.

I might try to parse my code between 32 and 64 bit.

I now should judge what would be the improvement in term of execution speed using LV64bit

(pattern matching operations should be improved in 64bit)

and once again find an optimum between performance and invested time!

I wish you all a very good weekend

PF

[rolfk]

Generally there is little to no performance gain to be expected from changing from 32 bit to 64 bit applications. There might be isolated cases but most claims about that are pure marketing claims. The only reasons where 64 Bit really gives you some true advantages is when using huge amountof memory for your data. This is not about 100MB of data but I'm talking about more than 1GB here. Only the most demanding image processing normally reaches these levels 9or a very badly programmed standard application that uses up huge memory blocks for no good reason).

[Shazlan]

Hi all,

Yeah, I've coupled 32 and 64 bit as a way around this issue and the system has been running ever since. Initially, I've used TCP as the means to communicate between 32 and 64 bit programs but now I think I've settled with Shared Variables... though I'm not sure whether this is the best method there is.

I'm using 64-bit not really for the processing speed but because the camera driver demands for it - if I use the 32-bit version, there are certain camera functions that may not be available and I don't know why. I've ran 1-to-1 comparison on the speed of the analysis (in LabVIEW) between 32 and 64 bit and they are about the same. However, IMO the additional RAM access when running in 64 bit allows me to have more image processing routine to run in parallel - thus increasing the speed and execution of the analysis. Thus, I do think that the gain is there.

My two cents.