My end goal is to create / trigger an alarm to tell the user there is an issue with controller’s SD Card, because we are writing CSV logs there.
I am worried about a situation where an SD card is not present (or has failed) and we automatically start writing the logs directly to the controller without anyone realizing.
Using a CC100 controller, when I CAA.File.Write to ‘/media/sd/Logs/’ without an SD card, the controller will create a directory locally under that path. This does not cause the File.Write FB to throw an error.
I could probably have Node RED inspect the /proc/mounts file but don’t want to add another layer if I do not need to.
Is there any way for the controller to tell CODESYS if it can see or write to the SD card?
IF xSDresult = FALSE THEN
myFbConfigTool( xExecute := xSDexecute, // Start the call once
sCallString := ‘./get_filesystem_data medium-list-json’, // Get the order number of the controller
sResultString => sSDresult // Get the result
);
IF myFbConfigTool.xDone THEN
xSDexecute := FALSE;
IF myFbConfigTool.xError = FALSE THEN
IF sSDresult = '[ "sd-card", "internal-flash-emmc" ]' THEN
xSDresult := TRUE; // SD card inserted
ELSIF sSDresult = '[ "internal-flash-emmc" ]' THEN
xSDresult := FALSE; // No SD card inserted
END_IF
END_IF
END_IF
The solution MikePsaltis provided does work for my specific situation, but I’ve been using ketan’s solution for the past week and I like it more.
ketan’s solution is more flexible and answers the broad question: “Does the system recognize an SD card?”, and does not depend on the ‘logs’ directory existing.
IF I have an SD card, THEN
I can create the ‘logs’ directory,
and then check if that directory creation step was successful using MikePsaltis’ solution.
Personally I’ve done another solution which is making a symlink:
ln -s /media/sd/ /home/codesys/PlcLogic/sd
This enable me to use the folder /home/codesys/PlcLogic/sd as my SD card and I have an error if it doesn’t exist and the link is broken since it can’t crate the folder.
I also like ketan’s approach but found two issues with this specific bit of code:
On some controllers the result string can be somewhat different: “internal-flash-nand” instead of “internal-flash-emmc”. I have seen this in an e!Cockpit project. It can be related to older firmware versions or older controller models.
Related: the above code snippet has logic for two resulting strings: it can be either ‘[ “sd-card”, “internal-flash-emmc” ]’ or ‘[ “internal-flash-emmc” ]’ . Logically there must also be a third option, where the sSDresult string has neither value. In that case no value gets assigned to xSDresult. In other words: xSDresult stays at the value it had before the code was executed. This is neither elegant nor robust.