Portal 2.1 closed beta

[WilliamM]

My first question is which firmware image should we be loading onto our nodes? There are two in the production folder:
SnapV2.1.0.sfi and debug_SnapV2.1.0.sfi
So far, I have been loading the debug image because it came up by default.

The next thing is that when I try to load a script onto multiple nodes, Portal stops after every two and must be told to load the script again.

With my snappy script, I am also getting an error message from my bridge node:
"Node ... called function sampleLq which does not exist"
but the function does exist and is executed successfully because the result is displayed on the 2 digit display on the proto board. If the bridge node has the old firmware, this error does not come up.

Last question for now: How can the list of active nodes be refreshed? Global ping does not pick up on nodes that have been turned off. In the old Portal, I just used the New Configuration button (the node name field is not important to us). In 2.1, the only way seems to be to disconnect and reconnect to the bridge.

[mgenti]

My first question is which firmware image should we be loading onto our nodes? There are two in the production folder:
SnapV2.1.0.sfi and debug_SnapV2.1.0.sfi
So far, I have been loading the debug image because it came up by default.

The debug firmare has extra checking builtin into it just like in version 2.0. The non-debug firmware has this functionality removed which allows for more space for your SNAPpy script.

The next thing is that when I try to load a script onto multiple nodes, Portal stops after every two and must be told to load the script again.
I have not seen this particular issue and will test this feature again. There is a known issue with multi-selecting nodes when Portal has also been selected. Can you double check that Portal is not getting selected with the nodes you are uploading to?

With my snappy script, I am also getting an error message from my bridge node:
"Node ... called function sampleLq which does not exist"
but the function does exist and is executed successfully because the result is displayed on the 2 digit display on the proto board. If the bridge node has the old firmware, this error does not come up.

With version 2.1 we are now checking SNAPpy scripts for unreferenced functions and variables. Can you please email us your script so that we can try and duplicate your issue?

Last question for now: How can the list of active nodes be refreshed? Global ping does not pick up on nodes that have been turned off. In the old Portal, I just used the New Configuration button (the node name field is not important to us). In 2.1, the only way seems to be to disconnect and reconnect to the bridge.
In version 2.1 and version 2.0 global PING does not pickup nodes that are off since they are unable to respond. If you are looking to remove nodes you can use multiselect and then remove the nodes. Also, you can turn on the "Node Watcher" which will try to contact nodes and remove nodes that don't respond. Also you can switch the view by choosing Active Nodes or All Nodes.

[mgenti]

The next thing is that when I try to load a script onto multiple nodes, Portal stops after every two and must be told to load the script again.

I have been able to reproduce this issue and it will be fixed in the next beta release of 2.1.

[kbanks]

My first question is which firmware image should we be loading onto our nodes? There are two in the production folder:
SnapV2.1.0.sfi and debug_SnapV2.1.0.sfi
So far, I have been loading the debug image because it came up by default.


The difference between the two builds was explained in the SNAP Release Notes. Which one you should load depends on how much error checking you need, versus how much script space you need. I suggest you run the "debug" build as long as your scripts continue to fit.

With my snappy script, I am also getting an error message from my bridge node:
"Node ... called function sampleLq which does not exist"
but the function does exist and is executed successfully because the result is displayed on the 2 digit display on the proto board.

PORTAL is complaining that HE does not have the function in question.

As we tried to explain in the various Release Notes (yes, more documentation is needed and is forthcoming), Portal now receives broadcasts too.

So, if one of your SNAP nodes is broadcasting a RPC sampleLq, Portal now gets that request too. You can put a "stub" function in your Portal script to make the error message go away. For example:


def sampleLq():
pass


If the bridge node has the old firmware, this error does not come up.

That is because the old bridge firmware did NOT pass broadcasts on to Portal, this is a new 2.1 feature. (Customers had been requesting that Portal become more like the other SNAP nodes in it's abilities).

Last question for now: How can the list of active nodes be refreshed? Global ping does not pick up on nodes that have been turned off. In the old Portal, I just used the New Configuration button (the node name field is not important to us). In 2.1, the only way seems to be to disconnect and reconnect to the bridge.

What was accomplished before with the "New Configuration" button (the green globe) is now done by selecting all of the nodes you want to clear out/refresh, and clicking on the "Delete" (red X) button in the Node Info pane.

You should then do a global ping.

[WilliamM]

PORTAL is complaining that HE does not have the function in question.That was, in fact, the problem. Adding the stub you suggested eliminated the error messages. The reason Portal only received the error from the bridge node is because I had limited the broadcast ttl to 1.

Also, you can turn on the "Node Watcher" which will try to contact nodes and remove nodes that don't respond. Also you can switch the view by choosing Active Nodes or All Nodes.Occasionally enabling the Node Watcher effectively works to refresh the list. But it seems to me that the list name "Active Nodes" is a bit misleading unless Node Watcher is left enabled.

Thanks to both of you for your responses.

[kbanks]

That was, in fact, the problem. Adding the stub you suggested eliminated the error messages.

Another way to get rid of the error message from Portal would be to change the checkbox at the bottom of the Logging Configuration dialog (look under the Options menu for Configure Logging...)

[WilliamM]

Another problem I'm experiencing when uploading my scripts to nodes (even individually) is that, often, Portal wont start uploading the script until "refresh" is pressed in Node View for that node.

[kbanks]

That problem is one we are currently working on. It happens on some PCs but not others.

The work-around is what you have already found - do a ping of sort sort to "kick start" communications.

[WilliamM]

Strangely, I was not having that problem when I first installed Portal 2.1 beta - it appeared only in the last few days.

ALSO, it was the cause for some of our confusion about Serial. We were not getting Portal to talk to the "smart device" (another PC) because the node which was connected to the smart device needed to be refreshed before the message(s) would go through. Now we know.

However, it means this bug affects things besides uploading scripts, which is bad.

[WilliamM]

It would be convenient if the nodes in Node Views could be listed in order of something other than their Network Address. For example, if trying to update the script in half of your nodes, it would be nice to list them in order of Device Image so that the half with the outdated version would be sequential (assuming versions are named differently). Another use could be listing them in order of Node Name, because (if the nodes all have the same script) you could easily find out how many nodes are registered/active (depending on use of configuration).

[mgenti]

We will add this to our feature bucket for ideas to look into implementing in the future.

[WilliamM]

using Portal 2.1.8 beta:
If I close the Event Log, there is no way to bring it back - neither with the icon, nor through the view menu. I can't exit Portal then because I get a Configuration Save Error. Killing the process and starting Portal again loads the old configuration and then everything is fine again.

[mgenti]

using Portal 2.1.8 beta:
If I close the Event Log, there is no way to bring it back - neither with the icon, nor through the view menu. I can't exit Portal then because I get a Configuration Save Error. Killing the process and starting Portal again loads the old configuration and then everything is fine again.

We have also seen this issue and it will be addressed when the next beta is released.