SigNotUpdated error on 2024 beta

[Crossle86]

I have updated a 2023 robot project to 2024 with CTRE 2024 beta vendordep. Since CTRE firmware has not been released yet, the cancoders on my robot are still on 2023 firmware. When my code tries to configure the cancoders it gets the error SigNotUpdated. Is this due to 2023 firmware on the cancoders or is something else amiss?

[CoryNessCTR]

That sounds like what I'd expect with the CANcoders on 2023 firmware if you're using v6. We do have the 2024 beta firmware available. In Tuner X you can select the 2024 year in the dropdown.

If you're using v5, then use the v5 dropdown instead.

If you're not using Tuner X, you can download all these firmware crfs from this repo. The current latest CANcoder crfs are here for example: https://github.com/CrossTheRoadElec/Phoenix-Releases/blob/master/ctr-device-firmware/CANCoder-vK-24.0.4.1-Phoenix6-Beta.crf https://github.com/CrossTheRoadElec/Phoenix-Releases/blob/master/ctr-device-firmware/CANCoder-vH-24.0.4.1-Phoenix6-Beta.crf

[Crossle86]

Thanks. Seems obvious to look here. What is the difference between the VK and VH variants? And, these files are labelled Phoenix6, but I plan on continuing with Phoenix 5 for the time being. Any problem with that?

[Crossle86]

Also, I am getting the error using v5 if that makes a difference.

[CoryNessCTR]

What is the difference between the VK and VH variants?

We have multiple versions starting last year due to the chip shortage that occurred, they're identical in performance, but each require a unique firmware. https://store.ctr-electronics.com/blog/cancoder-hardware-update/

The version is handled for you if you're using Tuner X.

Also, I am getting the error using v5 if that makes a difference.

I plan on continuing with Phoenix 5 for the time being

In that case, use the v5 dropdown in Tuner X, or continue using the 22.x firmware. The v5 firmware hasn't changed for the 2024 season, so the 2023 firmware should work. If you're still having issues with the v5 specific firmware, then I think we're going need some more information:

• Take a self-test snapshot of the CANcoders in Tuner and post here
• Can you provide the source code of what you're doing?
• Does this reproduce with one of our examples (such as the CANcoder example)?

As a side note, devices in v5 that are also available in v6 (CANcoder, TalonFX, Pigeon2) are being deprecated this year with the intention of removal for 2025. So you may want to look into porting your robot code to v6 anyway in preparation, along with using the new API's featureset and architecture. https://v6.docs.ctr-electronics.com/en/latest/docs/migration/migration-guide/index.html

[Crossle86]

More great information. I will get the snapshot later today. One more note, I see this error under simulation as well, but not on 2023 sim.

[Crossle86]

Boy this is my day for problems: installed Tuner X but it won't run:

Log Name: Application Source: Application Error Date: 11/29/2023 10:54:28 AM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: OSD59886.adserv.osd.wednet.edu Description: Faulting application name: phoenix-tuner-x.exe, version: 2024.5.2.0, time stamp: 0x65410000 Faulting module name: KERNELBASE.dll, version: 10.0.19041.1151, time stamp: 0x891df6d3 Exception code: 0xe0434352 Fault offset: 0x0000000000034ed9 Faulting process id: 0x3a74 Faulting application start time: 0x01da22f57a6d4e68 Faulting application path: C:\Program Files\WindowsApps\CTRElectronics.209251697EEC9_2024.5.3.0_x64fcacbrk06xgc2\phoenix-tuner-x.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: 0d4a1da3-d3b3-4672-acc2-a2a58f678720 Faulting package full name: CTRElectronics.209251697EEC9_2024.5.3.0_x64fcacbrk06xgc2 Faulting package-relative application ID: App Event Xml:

1000 0 2 100 0 0x80000000000000 36081 Application OSD59886.adserv.osd.wednet.edu phoenix-tuner-x.exe 2024.5.2.0 65410000 KERNELBASE.dll 10.0.19041.1151 891df6d3 e0434352 0000000000034ed9 3a74 01da22f57a6d4e68 C:\Program Files\WindowsApps\CTRElectronics.209251697EEC9_2024.5.3.0_x64__fcacbrk06xgc2\phoenix-tuner-x.exe C:\WINDOWS\System32\KERNELBASE.dll 0d4a1da3-d3b3-4672-acc2-a2a58f678720 CTRElectronics.209251697EEC9_2024.5.3.0_x64__fcacbrk06xgc2 App And: Log Name: Application Source: .NET Runtime Date: 11/29/2023 10:54:28 AM Event ID: 1026 Task Category: None Level: Error Keywords: Classic User: N/A Computer: OSD59886.adserv.osd.wednet.edu Description: Application: phoenix-tuner-x.exe CoreCLR Version: 8.0.23.53103 .NET Version: 8.0.0 Description: The process was terminated due to an unhandled exception. Exception Info: System.TypeInitializationException: The type initializer for '' threw an exception. ---> System.TypeInitializationException: The type initializer for 'WinRT.ActivationFactory`1' threw an exception. ---> System.Runtime.InteropServices.COMException (0x80040154): Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode) at WinRT.BaseActivationFactory..ctor(String typeNamespace, String typeFullName) at WinRT.ActivationFactory`1..cctor() --- End of inner exception stack trace --- at WinRT.ActivationFactory`1.ActivateInstance[I]() at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentInitializeOptions..ctor() at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize.AccessWindowsAppSDK() --- End of inner exception stack trace --- Event Xml: 1026 0 2 0 0 0x80000000000000 36080 Application OSD59886.adserv.osd.wednet.edu Application: phoenix-tuner-x.exe CoreCLR Version: 8.0.23.53103 .NET Version: 8.0.0 Description: The process was terminated due to an unhandled exception. Exception Info: System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.TypeInitializationException: The type initializer for 'WinRT.ActivationFactory`1' threw an exception. ---> System.Runtime.InteropServices.COMException (0x80040154): Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode) at WinRT.BaseActivationFactory..ctor(String typeNamespace, String typeFullName) at WinRT.ActivationFactory`1..cctor() --- End of inner exception stack trace --- at WinRT.ActivationFactory`1.ActivateInstance[I]() at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentInitializeOptions..ctor() at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize.AccessWindowsAppSDK() --- End of inner exception stack trace ---

[CoryNessCTR]

That looks like an old version of Tuner X that had a bug which we discovered and quickly patched, I'm really surprised you managed to download it at all. The version should be 2024.5.3.0.

Did you just install it from the Windows Store?

Can you try uninstalling it an re-installing it from the windows store? https://www.microsoft.com/store/productId/9NVV4PWDW27Z?ocid=pdpshare

[Crossle86]

Yes from store. Uninstalled and reinstalled using your link. Still fails. Note the application error log shows 5.2.0 at the top of error description but the file name it is executing says 5.3.0:

Log Name: Application Source: Application Error Date: 11/29/2023 11:30:50 AM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: OSD59886.adserv.osd.wednet.edu Description: Faulting application name: phoenix-tuner-x.exe, version: 2024.5.2.0, time stamp: 0x65410000 Faulting module name: KERNELBASE.dll, version: 10.0.19041.1151, time stamp: 0x891df6d3 Exception code: 0xe0434352 Fault offset: 0x0000000000034ed9 Faulting process id: 0x4644 Faulting application start time: 0x01da22fa8ee051da Faulting application path: C:\Program Files\WindowsApps\CTRElectronics.209251697EEC9_2024.5.3.0_x64fcacbrk06xgc2\phoenix-tuner-x.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: 7abc596b-f2e5-4c95-9f9e-57074bd187e2 Faulting package full name: CTRElectronics.209251697EEC9_2024.5.3.0_x64fcacbrk06xgc2 Faulting package-relative application ID: App Event Xml:

1000 0 2 100 0 0x80000000000000 36090 Application OSD59886.adserv.osd.wednet.edu phoenix-tuner-x.exe 2024.5.2.0 65410000 KERNELBASE.dll 10.0.19041.1151 891df6d3 e0434352 0000000000034ed9 4644 01da22fa8ee051da C:\Program Files\WindowsApps\CTRElectronics.209251697EEC9_2024.5.3.0_x64__fcacbrk06xgc2\phoenix-tuner-x.exe C:\WINDOWS\System32\KERNELBASE.dll 7abc596b-f2e5-4c95-9f9e-57074bd187e2 CTRElectronics.209251697EEC9_2024.5.3.0_x64__fcacbrk06xgc2 App

[Crossle86]

So kept looking as it failed under sim when device firmware is not in play. Found I was still on beta-1 of v5. Updated to beta-2 and now under sim it looks like it does under 2023 spec. No signotupdated error. Will test on robot this afternoon.

[Crossle86]

Well no joy. signotupdated gone from sim trace but is still present on real robot. Apparently no communication with the cancoders as we get CAN_MSG_NOT_FOUND error trying to read the cancoder absolute position.

[CoryNessCTR]

Do you have your robot code up on Github somewhere? And can you take that self test snapshot since you're in front of the robot?

[Crossle86]

So don't I need tuner x for the snapshot? If so I have not been able to install tuner x (see above). The failing code is in our swerve library (based on SDS example). The library is here https://github.com/ORF-4450/RobotLib and the source file is swerve/ctre/CanCoderFactoryBuilder.java at line 35.

A a possibly releated issue: configuration of Neos, which was working, now fails with kHALError. Was working yesterday...

[CoryNessCTR]

If you've got Tuner v1 you can use that for v5 device self test snapshots.

If other devices started failing, then I'd suspect the CAN bus may have electrical issues. If you can see the devices in Tuner v1 that's sufficient evidence against that, otherwise look at the LEDs and see if the CANcoders indicate good CAN comms or not. https://v6.docs.ctr-electronics.com/en/latest/docs/hardware-reference/cancoder/index.html#status-light-reference

Your robot code looks good to me as long as the CANcoders are on the RIO bus, which the self test snapshot can confirm along with providing other diagnostic information.

[daltzctr]

@Crossle86 would you mind sending some details such as

• Laptop name/model (if using a laptop)
• Windows OS build number (Settings -> System -> About)

To help investigate the Tuner X issue.

[daltzctr]

Additionally, can you try installing the latest Windows App SDK runtime available here?

[Crossle86]

If you've got Tuner v1 you can use that for v5 device self test snapshots.

If other devices started failing, then I'd suspect the CAN bus may have electrical issues. If you can see the devices in Tuner v1 that's sufficient evidence against that, otherwise look at the LEDs and see if the CANcoders indicate good CAN comms or not. https://v6.docs.ctr-electronics.com/en/latest/docs/hardware-reference/cancoder/index.html#status-light-reference

Your robot code looks good to me as long as the CANcoders are on the RIO bus, which the self test snapshot can confirm along with providing other diagnostic information.

Tuner v1 shows all ctre devices, snapshots look very clean, no errors, ideal/green, leds green. I can send snapshots but they all look like this: CANCoder3 (Left Front) | CAN ID is 3 This device is on the roboRIO's native CAN Bus Integrated Sensor:320.361 deg Position:320.361 deg Velocity:0.000 deg per sec Absolute Position (unsigned):320.449 deg On power cycle, sensor position syncs to the "Absolute Position", currently: 320.449 deg.

Magnet Field Strength: Ideal Magnet LED is green.

Battery:12.45 V

FRC Locked:1 Robot is enabled:0

"Blink / Clear Faults" to clear sticky faults.

Build:Nov 22 2023 00:21:26 Press "Refresh" to close.

This robot runs fine in 2023 spec.

[Crossle86]

Additionally, can you try installing the latest Windows App SDK runtime available here?

That seems to have solved the problem as Tuner X now runs as expected.

[Crossle86]

OK, so this gets better...problem steady, then per these messages I used Tuner v1 to check the cancoders and run self tests. Then got Tuner X working and looked at the bot, saw all the cancoders and did a self test on one of them. Posted the results here. Then decided to deploy the code one more time to see if anything had changed. Well it had. The code now runs normally, well almost.

Errors gone, driving robot around. All smiles other than no explanation. Then deployed again and deploy gives no errors but riolog is blank and DS indicates no robot code. Reboot Rio and that first deploy (just above) is still present on Rio and it runs. Drive robot around. Deploy again, no robot code. Reboot and off we go. This is as strange as it comes. Done for today.

[CoryNessCTR]

Then deployed again and deploy gives no errors but riolog is blank and DS indicates no robot code.

I'm not sure who's fault that would be. If it's reproducible with the robot code currently in the repo we may be able to try deploying it to see if it reproduces at all.

Reboot Rio and that first deploy (just above) is still present on Rio and it runs

This makes me think it may be related to the OutOfMemory issue present in Beta, but not getting anything from the DS log doesn't match the symptoms exactly: https://github.com/wpilibsuite/2024Beta/issues/39

Are you deploying to a RIO 1? Does it reproduce with any other example code?

[Crossle86]

This is on Rio 2. My problem does not match up well with 5790 but memory problems could manifest in different ways. Agreed deploy issue is not likely CTRE issue but it is interesting that the cancoder issue mysteriously vanished at more or less the same time the deploy issue started. I can't figure out what changed on the coder issue, but it appears to be gone for now.

I have had some ideas for further testing the deploy and will try example code and move this issue to WPILib, but it will be Monday at this point before I can get in front of the robot.

As for you testing our code, that would require our 2024 library to be posted on Jitpack and I have not got there yet. You would need to pull our RobotLib project and compile followed by executing the PublishToMavenLocal task to install the library in local maven cache. I understand if you have more important things to do.

Thanks for being so responsive on this issue. I will update this when I can do more testing.

[Crossle86]

Finally was able to do more testing. The deploy failure issue continues and is quite a problem. What is interesting is that every few successful deployments (when they do complete) the code displays the errors I originally reported on this issue as well as errors from the Neos. Deploy again and it works fine. This suggests that the original problem I reported here may be a symptom of the deployment issue.

I will pursue the deployment problem with WPILib.

[daltzctr]

I'm going to go ahead and close this issue as resolved, as the deployment issues are on WPILib's side and I believe they are taking measures to mitigate it.

In regards to easing the Tuner X process;

For individuals where the Windows Store version is failing to install, we have updated the offline installer to bundle Tuner X and include the fix I had you perform here.