RemoteGetFaradayStatus question

[JonF]

Hi all,

  I'm trying to write a new C# program that interfaces with the EPMA via the Remote interface but I keep butting up against a problem with RemoteGetFaradayState.

I've got everything else working and communicating with the EPMA (e.g. I know the Remote interface is communicating well), and I can successfully read and control motors, get tuneable specs etc, but I can't get this call to return the current state of the Faraday (i.e. in or out, as a boolean value).

In Visual Studio, it lists the RemoteGetFaradayState() as a void (i.e. it returns no value) - shouldn't this be returning a boolean that I can use to determine the faraday's current state?
RemoteGetAbsorbed() comes up as a float, as does RemoteGetMagnification() which are both listed in the documentation as Public Functions, but everything listed as a Public Sub seems to come up as a void in Visual Studio and I haven't figured out how to work with these...

What I'd like to do is simply include the faraday state within an IF statement, e.g.


if (RemoteGetFaradayState() == true) {
     //Do cool stuff
} else {
    //Don't do cool stuff
}



Any input would be appreciated, as I'm going round in circles trying to figure it out!
Anyone got any pointers?

[John Donovan]

RTFM!     

The documentation states:

Public Sub RemoteGetFaradayState(tbeamonflag As Boolean)
This procedure returns the current state of the faraday cup. True if beam is on (unblanked) or false if beam is off (blanked).

Usage:
Dim tbeamonflag as Boolean

Remote.RemoteGetFaradayState tbeamonflag

So yeah, it doesn't return a value as a function. Instead you have to pass a boolean variable, which returns the faraday cup state. I decided to make this more clear by modifying the TestRemote app (and code) which is distributed with the Remote installer as shown here:



In the meantime here is how it is called from VB6:

Code: [Select]

Dim tBeamOn As Boolean

Remote.RemoteGetFaradayState tBeamOn

If tBeamOn Then
FormMAIN.LabelGetFaradayState.Caption = "Beam On"
Else
FormMAIN.LabelGetFaradayState.Caption = "Beam Off"
End If

Hope that is more clear...

[JonF]

Ah, this would appear to be a VB vs C# thing then.

I can't compile code in C# with a declared but unassigned variable, in this case tBeamOn is declared as a boolean but never assigned to be true or false before it is called. Hm.

[John Donovan]

I would doubt that could be the case. Many of the functions in the Remote interface are prototyped the same way.

Maybe just assign the variable before the call. It will get overwritten when the procedure returns the value...

[JonF]

It will get overwritten when the procedure returns the value...

I think that's the problem, Visual Studio is telling me that RemoteGetFaradayStatus is a void and doesn't return anything. I can declare the tBeamOn as a bool outside of the local method and it seems happy enough with that, but it also tells me that the value is never used and is set by default to "false". I'm using Remote.RemoteGetFaradayStatus(tBeamOn).

I think I've got more googling to do!
Next week, anyway...

[John Donovan]

It will get overwritten when the procedure returns the value...

I think that's the problem, Visual Studio is telling me that RemoteGetFaradayStatus is a void and doesn't return anything. I can declare the tBeamOn as a bool outside of the local method and it seems happy enough with that, but it also tells me that the value is never used and is set by default to "false". I'm using Remote.RemoteGetFaradayStatus(tBeamOn).

I think I've got more googling to do!
Next week, anyway...

Yes the procedure call returns a void (nothing).

And it should be Remote.RemoteGetFaradayState (not status).

Go home!   

[JonF]

And it should be Remote.RemoteGetFaradayState (not status).

A typo in my post, not the code fortunately!

Go home!   

This was going to bug me all weekend, so I came back to this after a break and figured it out. Was surprisingly simple!

In C#, the below doesn't work

        private void GetFaradayState(object sender, EventArgs e)
        {
            bool tBeamOn = false;

            Remote.RemoteGetFaradayState(tBeamOn);

            if (tBeamOn == true)
            {
                Console.WriteLine("Beam On!");
            }
            else
            {
                Console.WriteLine("Beam Off :-(");
            }

        }



This appears to be a difference in the way VB and C# treat the tBeamOn variable and what a void can and can't do with an object.   
If we change Remote.RemoteGetFaradayState(tBeamOn); to reference the data instead Remote.RemoteGetFaradayState(ref tBeamOn);, it works :-)


        private void GetFaradayState(object sender, EventArgs e)
        {
            bool tBeamOn = false;

            Remote.RemoteGetFaradayState(ref tBeamOn);

            if (tBeamOn == true)
            {
                Console.WriteLine("Beam On!");
            }
            else
            {
                Console.WriteLine("Beam Off :-(");
            }

        }


I can enjoy my weekend now!

[John Donovan]

This appears to be a difference in the way VB and C# treat the tBeamOn variable and what a void can and can't do with an object.   
If we change Remote.RemoteGetFaradayState(tBeamOn); to reference the data instead Remote.RemoteGetFaradayState(ref tBeamOn);, it works :-)


        private void GetFaradayState(object sender, EventArgs e)
        {
            bool tBeamOn = false;

            Remote.RemoteGetFaradayState(ref tBeamOn);

            if (tBeamOn == true)
            {
                Console.WriteLine("Beam On!");
            }
            else
            {
                Console.WriteLine("Beam Off :-(");
            }

        }


I can enjoy my weekend now!

Yes. In VB and VBA parameters are by default passed by reference. 

In my mind I had always envisioned people using the Remote interface from Excel, so this issue would not need to be explicitly stated, but my bad for those working in other languages.

Also I would not mention this usually, but since you have both a JEOL and Cameca EPMA instrument in your lab, I should say that the Remote interface should allow you to write hardware independent code (if written correctly).  That means that the same macro/apps should (in theory anyway) be able to run on both your JEOL and Cameca instruments.