Script running Java does not work the second time

Dear all

I would like to use a GUI to run some java code that starts a pump. I did not write the java code nor have access to it (only the compiled .jar file). When I run this code the first time, everything works fine and the pump turns. When I run the code the second time, I get a Java exception (see exception text below). Closing Matlab and opening it back up allows me to run the code again.

I guess there is some java caching going on or variables still stored, but I can't figure it out.

Thank you very much

Full error message:

Error using Copy_of_gui/ConnectButtonPushed (line 45)
Java exception occurred:
java.lang.UnsatisfiedLinkError: Native Library C:\Users\name.surname\AppData\Local\Temp\.jsftdi\jsftdi_x64.dll already loaded in another classloader

	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1907)

	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)

	at java.lang.Runtime.load0(Runtime.java:809)

	at java.lang.System.load(System.java:1086)

	at companyname.jserial.helpers.Utils.loadLibrary(Utils.java:166)

	at companyname.jserial.jserial.FTDI.<clinit>(FTDI.java:20)

	at companyname.jserial.companynameevalboard.companynameevalboard.connectFTDI(companynameevalboard.java:150)


Error in matlab.apps.AppBase>@(source,event)executeCallback(ams,app,callback,requiresEventData,event) (line 54)
            newCallback = @(source, event)executeCallback(ams, ...
                                          ^^^^^^^^^^^^^^^^^^^^^^^^
 
Error while evaluating Button PrivateButtonPushedFcn.

Important lines of code (full file attached):

function ExitButtonPushed(app, event)
            bOk = app.pump.stop();
            app.delete
        end

function ConnectButtonPushed(app, event)
    addpath 'X:\matlab\companyname_matlab_cleaning\tasks\PUMP' %path to common.m including companynameevalboard
    javaaddpath('X:\matlab\companyname_java_library\JcompanynameSerial\dist\JcompanynameSerial.jar') %path to compiled java code including FTDI communication
    addpath 'X:\matlab\companyname_java_library\JcompanynameSerial\scripts\ISP' % path to pump.m
    app.sd = Common.companynameevalboard(); %create evalboard object
    bOk = app.sd.connectFTDI("I2CM"); %connect to evalboard over FTDI chip, this line gives the error
    
    app.pump= Pump(app.sd, I2Caddress, 'pumpname'); %connect to the pump via evalboard
    bOk = app.pump.move(0, 0x00); %this command moves the pump forever
end

[dpb]

Error using Copy_of_gui/ConnectButtonPushed (line 45)
Java exception occurred:
java.lang.UnsatisfiedLinkError: 
Native Library C:\Users\name.surname\AppData\Local\Temp\.jsftdi\jsftdi_x64.dll
 already loaded in another classloader

I wrapped the long line so can see what it is really complaining about --

I "know nuthink!" (a la Sgt Schultz) of Java, but looks to me from the above and from the code for ConnectButtonPushed that the problem would be trying to reload the same thing the second time. I'd think the

addpath 'X:\matlab\companyname_matlab_cleaning\tasks\PUMP' %path to common.m including companynameevalboard
javaaddpath('X:\matlab\companyname_java_library\JcompanynameSerial\dist\JcompanynameSerial.jar') %path to compiled java code including FTDI communication
addpath 'X:\matlab\companyname_java_library\JcompanynameSerial\scripts\ISP' % path to pump.m
app.pump= Pump(app.sd, I2Caddress, 'pumpname'); %connect to the pump via evalboard

code should be in the startup code to execute only once per session and then the control would talk to the pump object. There then should be some way to close and clear it when through as well.

[Walter Roberson]

I agree, you should create app.pump once and then use it as needed. And of course you should have some kind of cleanup code for it after you are finally done with it.

    bOk = app.pump.move(0, 0x00); %this command moves the pump forever

That leads me to worry that you are possibly running the app until control-C instead of having some kind of graceful stop to the pump.

[dpb]

@A2.0 didn't provide us the test board/pump vendor data so we can't tell what features it may support. One certainly would expect there's a numeric code to turn it back off and it's possible it might support variable speed as well; we simply can't tell without a reference. And, of course, to release the object itself as you note.