meat-inc / sharpwrap2534 Goto Github PK

License file says "Copyright (C) 2021 Zack Walsh", meaning this library is not (apparently) open source.

@ZacharyWalsh57 could you elaborate if this library is actually open source, if yes what license?

When running simulations, messages are failing to send when a flow control filter is needed.

For some reason, generation of simulations appears to be broken? When testing the log file set from a 2023 Camry, I found that TIS won't scan the simulation. It appears as though that even though all communications are being logged inside the expressions file, the actual simulation is missing command routines.

This needs to be addressed and fixed ASAP. Should also include a new release of the SharpSimulator once completed.

We should be able to add basic tests like VIN Number reading into ALL simulations. This would be HUGE for allowing multiple tools to talk to single simulations.

I would love to be able to write a 64bit C# application that can call 32bit J2534 DLLs (or any x86 32 bit DLL for that matter). It would require a separate process and to communicate via shared memory, windows pipes or something along those lines.

Have you ever considered doing something like this?

Currently I'm trying to setup two channels, one for ISO14230 and one for CAN sniffing. I've been able to make it work by duplicating the J2534Channels outside of the SharpSession and modifying the wrapper functions accordingly, but I'm assuming there's a way to do this natively within the SharpSession object.

Do you happen to have any examples showing the intended way of setting up multiple channels? Trying to use PTConnect() multiple times just results in all the DeviceChannels[] (stored in the SharpSession) being overwritten by the most recent channel.

https://github.com/MEAT-Inc/SharpWrap2534/blob/77a7cf757ab5e327acd8811066702325a5a670f9/SharpWrapper/PassThruSupport/PtTextTableGenerator.cs#LL59C59-L59C59

I seem to be getting an error here if you want to take a gander @ZacharyWalsh57 :)

Sometimes, sending responses fails since flow control messages take a hot second to fire off. By converting long messages into frame pad messages, we can hopefully prevent the timeout issues seen during some testing routines.

Need to build and test both a 29 bit and Mixed mode simulation configuration for the SharpSimulator